Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"

On Mon, Feb 20, 2023 at 7:33 PM Alex Henrie [off-list ref] wrote:

Tao, the primary motivation behind the `git pull` warning was to help
prevent users from merging main into a topic branch when that's not
what they really want to do. The fact that novices sometimes do that
has been a point of pain for many people, including Linus Torvalds:
See "Don't merge upstream code at random points" at [1] and "github
creates absolutely useless garbage merges" at [2].

If you're seeing users merge main into topic branches without a good
reason, that does sound like more of an education problem than a
bad-defaults problem.

I would disagree on two points:

1. The need for merging in the upstream varies project by project,
user by user, etc. If you are working on a part of a system where you
can reasonably assume the ground will not shift under your feet,
awesome, lucky you! Many users are not so fortunate, and need to
regularly ensure that their changes still make sense in the
ever-changing upstream context.

Regularly (whatever that means to you) merging in the upstream is the
simplest way of achieving that. If you're working on your own or as
part of a team that's happy to handle coordinated rebasing, then
rebasing is a potentially-more-satisfying way of achieving the same
end - either way, assuming that their changes will make sense in the
upstream context is simply not a luxury many users can afford over any
period of time.

Now, you note that Linus advocates for merging specific points,
because he doesn't respect you merging "random crap" from a branch
called "linus" - that's fine, but many projects strive to keep a
specific trunk branch "evergreen" in order to minimize late conflicts
are maximize coordination - there's a pretty cool site about it:
https://trunkbaseddevelopment.com/ - this is not really different to
Linus' advice except that the goal is to make there *never* be "random
crap" on the upstream.

2. The fact that the commit history of non-expert git users (those who
should not be using rebase, especially in teams) are so often...
spidery... is why the "Squash" option of pull requests / merge
requests is so popular in centralized workflows (GitHub, GitLab,
BitBucket, etc).

If your project follows a "merge down, squash up" strategy with a
well-CI-guarded evergreen trunk on a central server, there's simply no
reason to *require* your users to become rebasing experts - you can
let them use simple merge-based workflows, keep your trunk clean by
squashing away their complex commit graphs, let them merge down
whenever they need or want to, etc.

We might still want to change the default to
better support the more unusual cases, but

Do we have any analysis/understanding of how common workflows like
that of the git or linux projects are, vs github-style fork-based
projects, vs straight-up single central server projects?

I'm not sure what you mean by "unusual", but I don't think "avoid
rebase unless you really know what you're doing, merge down at will,
we will squash your contribution in the pull/merge request at the end
anyway" is an unusual flow at all nowadays.

if you're going for a quick
win, it would be faster to teach users the wisdom of not mixing rebase
and merge in the first place.

"teach [...] wisdom" is a good one! No, seriously - of course I'm
going to do the best I can to prevent my users from falling into the
traps surrounding them - but my point here is that *we simply
shouldn't have pointless traps*. Offering a command that can cause
significant "harm" (time loss, frustration, etc), silently... just
doesn't seem like a good idea.

[1] https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
[2] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/ (local)