Re: [PATCH] pull: introduce --merge option

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jun 28, 2021, 04:52 UTC
Message-ID: <60d955a473187_aaf7e208f6@natae.notmuch>
In-Reply-To: <CAMMLpeQ9BVNHqk2p748+4+ufuWJ46fYUnVvMvwFPxh3N--ASPg@mail.gmail.com>

Alex Henrie wrote:

Show 11 quoted lines

> On Sun, Jun 27, 2021 at 9:16 PM Felipe Contreras
> <felipe.contreras@gmail.com> 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@mail.gmail.com/
> 
> 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.

Show 9 quoted lines

> > ---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/ [2] https://lore.kernel.org/git/CABPp-BESMs1tuVoLFMy-BahSChFz7oANqTaeJShFa_zDbEnvBA@mail.gmail.com/

-- 
Felipe Contreras