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

On Tue, Feb 21, 2023 at 8:40 AM Tao Klerks [off-list ref] wrote:

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.

The advantage to that workflow is that you don't have to teach users
how to rebase. (Whether the actual process of merging or rebasing is
easier, assuming that the user knows how to do both, is debatable and
likely depends a lot on the particular situation.) The disadvantage is
that even merge requests that seem like they only need one commit
often turn into multiple commits, and squashing all of those commits
together indiscriminately both makes it harder for the reviewer to
follow the progression of steps the developer took and decreases the
usefulness of tools like `git blame` and `git bisect`. For example,
the patch series that I sent to add a rebase.merges option will be 3
or 4 commits in the end, and other developers have good reasons to ask
me to keep those commits separate instead of squashing them all into a
single patch. On top of that, if your developers get the impression
that all projects on GitHub/GitLab/whatever use the same workflow,
they are likely to cause headaches when they present spidery merge
requests to other projects. If you are OK with those tradeoffs then
that's fine, Git will support you. My point is simply that every
workflow has its advantages and disadvantages, and there's no workflow
that solves every problem.

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 don't have any statistics (although I would love to see them if they
exist), but I do know that all of these workflows are common enough
that `git pull` can't assume what the user wants. The warning exists
to try to prevent the user from shooting themself in the foot.

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.

The unusual cases are the ones where you mix merge and rebase on your
own topic branch. Your developers did that accidentally (despite `git
pull` trying to warn them) and suffered because of it, because it
isn't well supported right now. I think we all agree that it should be
better supported, we just disagree on how to get there.

-Alex