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

From: Alex Henrie <alexhenrie24@gmail.com>
Date: Feb 21, 2023, 17:45 UTC
Message-ID: <CAMMLpeR0Z1Ay_ubHuGVz4f5RfxhhmoKsNq=OsaL5TB3WHXfJvA@mail.gmail.com>
In-Reply-To: <CAPMMpohfF5Cwgxt_G+Gp4rNPGTJZcQfmgEoJcFi_Kzbv2XGuog@mail.gmail.com>

On Tue, Feb 21, 2023 at 8:40 AM Tao Klerks <tao@klerks.biz> wrote:

Show 13 quoted lines

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