git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Alex Henrie <alexhenrie24@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] pull: introduce --merge option
Date: Sun, 27 Jun 2021 23:52:52 -0500	[thread overview]
Message-ID: <60d955a473187_aaf7e208f6@natae.notmuch> (raw)
In-Reply-To: <CAMMLpeQ9BVNHqk2p748+4+ufuWJ46fYUnVvMvwFPxh3N--ASPg@mail.gmail.com>

Alex Henrie wrote:
> 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.

> > ---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

      reply	other threads:[~2021-06-28  4:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28  3:16 [PATCH] pull: introduce --merge option Felipe Contreras
2021-06-28  3:51 ` Alex Henrie
2021-06-28  4:52   ` Felipe Contreras [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60d955a473187_aaf7e208f6@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=alexhenrie24@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).