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

On Mon, Feb 20, 2023 at 7:33 PM Alex Henrie <alexhenrie24@gmail.com> wrote:

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.

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.

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