Alex Henrie wrote:
On Sun, Jun 27, 2021 at 9:16 PM Felipe Contreras
[off-list ref] wrote:
quoted
The idea came after a comment from Linus Torvalds regarding what should
be the default mode of "git pull" and why [1].
[1] https://lore.kernel.org/git/CA+55aFz2Uvq4vmyjJPao5tS-uuVvKm6mbP7Uz8sdq1VMxMGJCw@mail.gmail.com/ (local)
Oh wow, I didn't realize that Linus gave his opinion on the subject
back in 2013, and he suggested doing nearly exactly what we are trying
to do now.
Indeed. I incorporated his feedback--along with the feedback of many
others--in my proposal.
I have been re-reading the old threads to write a blog post, and the
whole story starts from 2008. At this point I have probably read more
than one thousand emails, and I'm still far from done.
Actually now that I'm re-reading the draft, the first suggestion of
--merge came from Thomas Rast in 2009 [1] (I forgot).
Long story short: *everyone* (and I do mean everyone) is in favor making
ff-only the default. The disagreements come from how we get there.
quoted
---no-rebase::
- Override earlier --rebase.
+-m::
+--merge::
+ Force a merge.
++
+Previously this was --no-rebase, but that usage has been deprecated.
I don't think --no-rebase should be "deprecated", at least not yet.
Deprecated means that we discourage people from using it. It doesn't
mean it's unsupported.
It's not obsolete.
After all, the equivalent config option is still pull.rebase=false.
Yes, but the equivalent from the command line is:
git pull --rebase=false
And that's still properly documented:
-r, --rebase[=false|true|merges|preserve|interactive]
Also, --merge doesn't necessarily force a merge because it does not
imply --no-ff.
This is a bit of semantics that I have discussed before with Elijah, and
somehow I managed to convince him [2] that fast-forward can be used as
an adverb, and in fact it already is in plenty of the documentation.
Basically this:
git merge --ff-only
Does a fast-forward merge. So it's a merge of a special kind. What kind?
The fast-forward kind.
I would prefer to list --no-rebase, -m, and --merge
together on the same line and leave the description alone.
I prefer to deprecate --no-rebase. Both --rebase=false and --merge are
less cumbersome alternatives.
But I'm not married to this. If other people want to keep --no-rebase at
the same level as the other two options, I would not object to it.
But other than the documentation and the commit message, I like the
idea here, and I think it will make Git a lot more user-friendly.
Good. And for the record I think if this patch is not merged, eventually
somebody else will send something along these lines, since I'm not the
first person to think of it, nor will I be the last.
Cheers.
[1] https://lore.kernel.org/git/200910201947.50423.trast@student.ethz.ch/ (local)
[2] https://lore.kernel.org/git/CABPp-BESMs1tuVoLFMy-BahSChFz7oANqTaeJShFa_zDbEnvBA@mail.gmail.com/ (local)
--
Felipe Contreras