Re: [RFC 2/2] pull: default pull.ff to "only" when pull.rebase is not set either

[Felipe Contreras <felipe.contreras@gmail.com>]

On Thu, Dec 3, 2020 at 1:30 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> >> That would require changing the semantics of --ff-only, so that "git
> >> pull --no-rebase --ff-only" doesn't make sense (as --ff-only is
> >> overridden by --no-rebase).
> >
> > I do not think such a conclusion follows from "we do not want to use
> > the 'by default force the --ff-only' when the user chooses between
> > merge and rebase".  Specifically, I do not agree with "as --ff-only
> > is overridden" in your statement.
>
> Ah, sorry, I mis-read your three lines above.
>
> There are currently two ways "git pull" consolidates your work with
> the other history.  By default, you are "pulling" work from your
> contributors (and that is what "pull request" means---contributors
> ask you to pull, and you take their work at your discretion) and the
> only way that makes sense is to merge their history into yours.

And this is the reason why I warn about using one's worldview too
much. The *vast* majority of users do not use "git pull" this way;
there are more contributors than maintainers.

What they want is to "merge your history into theirs", not the other
way around. So the only way they can do that correctly is by doing
"git fetch" + "git merge". Which is why so many people say to avoid
"git pull" altogether.

So, a newcomer that doesn't know much about git and does a "git pull",
is pretty much guaranteed to do something unintended. If he/she is a
user, the merge will have the parents the other way around, but even
as a maintainer, the project might not like merges, and he/she will
introduce an unwanted merge, or worse; an evil merge.

> The other is you are updating your branch by rebasing your work on
> top of what happend in their history.

Again, what the user might want is the opposite. If the user is a
maintainer, these two:

  git pull --merge github john
  git pull --rebase github john

Should be about their history to yours (or on top of yours).

> And if we introduce a third-way, i.e. "we do not handle the case
> where you have your own development at all, this is only to maintain
> pristine copy from your upstream", and repurpose "--ff-only" for
> that purpose, yes, what you said above does make sense.  At that
> point, there is no reason to disagree with "as --ff-only is
> overridden" part of your statement---in your new world, "--ff-only"
> is redesigned to act that way.

That's right. Otherwise "git pull --no-rebase" will fail; you will
have to specify --ff (or --no-ff) for it to work. And that doesn't
make sense to me.

Specifying --no-rebase should override the default --ff-only mode (or
pull.mode=ff-only).

> In retrospect, "git pull --rebase" was a UI mistake.  What the other
> side means is totally different in the operation from what the other
> side is in "git pull".  The former is for you to catch up with your
> upstream and the latter is for you, who _is_ the upstream to others,
> to take others work in as their upstream.  If we instead introduced
> a separate command, say "git update", that is "fetch followed by
> rebase" (just like "git pull" is "fetch followed by merge"), to
> rebase your work on top of updated upstream, there wouldn't be a
> need for us to be having this discussion.
>
> It probably is water under the bridge at this point.  Perhaps if
> somebody builds a time-machine for me, I'll go back 13 years and
> give my younger self this wisdom ;-)

You don't have to go back 13 years ago, you can go back 6 years ago
when I wrote all the patches for git update [1], explained the summary
of the problem [2], and others urged git developers to pay more
attention to the patch [3].

But as you say; water under the bridge.

Today there are 3 things to do:

1. Improve the annoying warning
2. Consider changing the semantics of --ff-only, or implement pull.mode=ff-only
3. Consider a new "git update" command

Since my new (2020) patches for pull.mode (solve 1 and 2) have not
been reviewed, I'm thinking there's too much inertia and perhaps it's
time to cash in the chips and concentrate only on 1.

Cheers.

[1] https://github.com/felipec/git/commit/d38f1641fc33535aa3c92cf6d3a30334324d3488
[2] https://lore.kernel.org/git/5366db742d494_18f9e4b308aa@nysa.notmuch/
[3] https://lore.kernel.org/git/CAGK7Mr4uucBN=17ph5pBjrz7yP60By1sERU9oBL+c2-gsMDmrw@mail.gmail.com/

-- 
Felipe Contreras