On 18/02/2023 03:17, Elijah Newren wrote:
On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote:
On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks <tao@xxxxxxxxxx> wrote:
If there's an appetite for it, I would love to contribute to a
multi-year adventure to change git's behavior, little by little, until
the behavior of "rebase=merges" is the default, and the old behavior
becomes a different option like
"rebase=copy-merged-commits-to-flatten"
I know you had a lot to say in your last email, but I'd like to focus
on this point. I would be OK with the proposed patch if it were part
of a larger effort to make --rebase-merges the default behavior of
`git rebase`. That seems like an achievable goal, and I don't think it
would take multiple years, maybe one year at the most. The process
would look something like this:
1. Add a --no-rebase-merges option to `git rebase`.
2. Add a rebase.merges config option.
3. Add a warning to `git rebase` that appears if rebase.merges is
unset and neither --rebase-merges nor --no-rebase-merges is given. The
warning would advise the user that the default behavior of `git
rebase` will change in a future release and suggest setting
rebase.merges=no-rebase-cousins to get the new behavior now.
4. Change the `git pull` advice to recommend --rebase=merges and
pull.rebase=merges.
5. Wait a couple of releases.
6. Change the default behavior of `git rebase` to `git rebase
--rebase-merges` and the default behavior of `git pull --rebase` to
`git pull --rebase=merges`. At the same time, remove the warning from
`git rebase`. The old `git pull` behavior would still be available as
`git pull --rebase=true`.
7. Change the `git pull` advice to recommend the short and simple
--rebase option again (leaving the recommendation of
pull.rebase=merges for the config option).
Does that sound reasonable? I think I could lend a hand with steps 1-3.
One concern I have is that "--rebase-merges" itself has negative user
surprises in store. In particular, "--rebase-merges", despite its
name, does not rebase merges. It uses the existing author & commit
message info, but otherwise just discards the existing merge and
creates a new one. Any information it contained about fixing
conflicts, or making adjustments to make the two branches work
together, is summarily and silently discarded.
That's a good point. Another potentially surprising behavior is that
when I'm rebasing an integration branch with -rno-rebase-cousins then if
one of the topic branches merged into the integration branch happens to
share the same base as the integration branch itself the topic branch
gets rebased as well. -rno-rebase-cousins is also slower that it needs
to be because it creates a todo list that contains all the commits on
the topic branches merged into the integration branch rather than just
the merges. The commits on the topic branches are fast-forwarded rather
than rewritten so long as they don't share the same base as the
integration branch but it noticeably slower than using a todo list with
just the merge commands.
My personal opinion would be adding such a capability should be step
2.5 in your list, though I suspect that would make Tao unhappy (it's a
non-trivial amount of work, unlike the other steps in your list).
I've got a couple of patches[1] that cherry-pick the merge if only one
of the parents has changed. I've never tried upstreaming them as it is
only a partial solution to the problem of rebasing merges but that
approach should work well with "git pull --rebase=merges" as only the
upstream side will have changed (when rebasing my git integration branch
with that patch the merges are cherry-picked). They might make a useful
starting point if anyone wants to try and improve the rebasing of merges.
Best Wishes
Phillip
[1] https://github.com/phillipwood/git/commits/rebase-cherry-pick-merges
