Alex Henrie wrote: > On Sun, Jun 27, 2021 at 9:16 PM Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: > > > > 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@xxxxxxxxxxxxxx/ > > 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. > > ---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@xxxxxxxxxxxxxxx/ [2] https://lore.kernel.org/git/CABPp-BESMs1tuVoLFMy-BahSChFz7oANqTaeJShFa_zDbEnvBA@xxxxxxxxxxxxxx/ -- Felipe Contreras
