Re: [PATCH v2 02/14] pull: improve default warning

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

On Tue, Dec 8, 2020 at 2:16 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > That is exemplified by the fact that this whole thread started from a
> > user that refused to configure pull.rebase and expected the Git
> > project to just do the right thing (which is basically choosing a
> > useful default).
>
> Which is basically asking for impossible, and I do not think it is a
> good idea to focus our effort to satisfy such a request in general.
> There is no useful default that suits everybody in this particular
> case.

I think I already made this point, but this is the nirvana fallacy
(the perfect is the enemy of the good) [1]. Just because we can't have
the perfect solution doesn't mean we can't pursue something better
than the current state.

What was asked was not a perfect solution, just a better default. If
right now the default is good enough for 20% of users, and with some
changes we can make it better for 40%... that's progress. We don't
have to wait until we have a solution for 100% of them.

> But for anybody who uses git for real (read: produces his or her own
> history), it would be pretty much a useless default that forces the
> user to say rebase or merge every time 'git pull' is run.

This is not true.

I will give you a real example.

I create a branch named "fc/margin" based on "master", I make my
changes, I push the branch to my personal repository, and create a
pull request. This is the typical triangular workflow.

Then I do "git pull [--ff-only]". What will happen? 1) As long as my
branch is not merged upstream, I will get an error, and my branch will
stay where it is. But then, 2) when my branch is finally merged to
"master" it will be fast-forwarded, so now both "fc/margin" and
"origin/master" point to the same commit.

A. Did I use git "for real"? (produce my own history)
B. Was "git pull [--ff-only]" useful in this case?

I think that one of the problems is that Git has so many different
workflows that finding another person that has your same workflow is
like finding a person with your same birthday. It's not impossible,
just takes more than a few tries.

Also, and this is not a deriding question, I'm genuinely curious: how
often do you send pull requests?

BTW, this example above is real [2]. In my particular case very often
I'm creating history, I'm just not the one pulling it.

> But other than that, I do not
> see any real use for the choice, which would mean in practice,
> pull.mode would have only two useful values, rebase or merge.  That
> does not feel a good enough reason to supersede what already exists,
> which is pull.rebase=yes/no.

The fact that you don't see the use doesn't mean the use is not there.

Why do you think this issue keeps coming back again and again, and
again? And every time it comes back people say the same thing:
"fast-forward-only merges should be the default".

Unfortunately it's not that simple. It's a rabbit hole that leads to a
cacophony of issues in git pull. However, we can fix some of them
*today*.

> Perhaps there is a good reason why certain classes of users would
> want to configure pull.mode=ff-only (i.e. "I might type 'git pull'
> by mistake, please stop me if I did so on a branch I have real work
> already.").  If that is the case, I would very much agree that it
> would be awkward to express that choice in the current framework to
> choose between pull.rebase=yes/no and pull.mode=(rebase/merge/ff-only)
> would become a lot easier to explain.

There's three options:

1. pull.ff=only (that doesn't work IMO)
2. pull.rebase=ff-only (that works, but it's kind of wonky)
3. pull.mode=ff-only (maybe it should be pull.mode=fast-forward)

But the current option (pull.mode=merge) just doesn't fly. And BTW, I
did create a poll in reddit's r/git [3], and 67% (of 789) said they
didn't specify anything, just "git pull".

So, most people simply do "git pull" and hope for the best.

Moreover, in 2014 I said if we don't fix it now (which is likely), we
will be discussing it again [4], and here we are now. And I'm saying
it again: leave the mode as "merge", we will be discussing this again.

I could do some mail archeology if you want, but this issue starts to
be mentioned at least since 2010, and virtually everyone (except one
person) agreed the default must change, even Linus Torvalds. Reading
back what Linus said [5], it's something very, *very* close to what
I'm proposing (I would argue my proposal is better).

So you let me know. Do you want me to dig a decade of discussions and
coalesce those conclusions into a summary so we can decide how to
proceed? Or should I drop the plan? Only that if we drop it, I
*guarantee* we will discuss it yet again years later.

Moreover, this is the reason why I split the series in 3. Even if you
decide you don't want to change the default, part I of the series can
still be merged *today*, and everyone would benefit.

Cheers.

[1] https://en.wikipedia.org/wiki/Nirvana_fallacy
[2] https://github.com/git/git.github.io/commit/5d90fd64d80847e3d873da43515750bc04b639e2
[3] https://www.reddit.com/r/git/comments/k6uj7c/do_you_use_git_pull/
[4] https://lore.kernel.org/git/536429e97cf5a_200c12912f094@nysa.notmuch/
[5] https://lore.kernel.org/git/CA+55aFz2Uvq4vmyjJPao5tS-uuVvKm6mbP7Uz8sdq1VMxMGJCw@mail.gmail.com/

-- 
Felipe Contreras