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

From: Elijah Newren <newren@gmail.com>
Date: Feb 20, 2023, 16:46 UTC
Message-ID: <CABPp-BEAqP7maTVw82Qr8mn-sxPzXmHnE_mTKf2pg6hVYAJSUw@mail.gmail.com>
In-Reply-To: <c3ef69e0-c37a-01fe-a40a-c2940e329793@dunelm.org.uk>

Hi Phillip,

On Sat, Feb 18, 2023 at 8:39 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 22 quoted lines

>
> On 18/02/2023 03:17, Elijah Newren wrote:
> >
> > 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.

Yeah, modifying rebase to accept a general range expression (instead of assuming upstream..HEAD) would really help. Then, to get just the parts you are interested in, you could use a range with extra commit exclusions and additional qualifiers like --ancestry-path=<commit> and --first-parent. In fact, you could also list multiple branches (none of which necessarily fully contains any of the others) to replay multiple branches at a time. (See [2] for where I discuss this more, though focusing on the --ancestry-path=<commit> part of it.).

But, it'd also fundamentally break existing workflows, so it might have to be a new command, perhaps `git replay`. However, there's multiple other improvements needed in rebase (such as not wasting time updating the working tree or index or reflog for every commit, or wasting time writing N control files when we could move to 1 control file, and allowing working on branches that aren't checked out) that I think would likely also break compatibility, so maybe another command is a good idea anyway[3].

[2] https://lore.kernel.org/git/CABPp-BHmj+QCBFDrH77iNfEU41V=UDu7nhBYkAbCsbXhshJzzw@mail.gmail.com/ [3] https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt

Show 11 quoted lines

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

I've actually put quite a bit of time into this problem. I have outlined what I think is a full solution to the rebasing of merges problem space at [4], which expands on my earlier discussion with Johannes on-list over at [5] (which in turn was a follow-up to previous discussions that you, Johannes, and several others had years ago). If you're interested and have any thoughts on my plans for this problem space, I'd love to hear it. You tend to have very strong insights on everything xdiff, sequencer, and rebasing related. My "replay" branch contains a partial implementation, but it's not really usable for anything rebase-merges-related yet, so you'd mostly have to go with my writeups.

A warning, though, that I won't be able to respond to feedback on this topic very soon. I will definitely get back to working on it, but it's been much more challenging with more limited git time these days. Unfortunately, the current economic environment reduces the number of ways possible to extend the amount of time available for working on Git, but one way or another I'll eventually get back to this problem and implement my ideas, unless someone beats me to it.

[4] https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt#L264-L341 [5] https://lore.kernel.org/git/CABPp-BHWVO5VRhr1-Ou60F1wjKzJZ1e_dC01Mmzs+qB9kGayww@mail.gmail.com/