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

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 22, 2023, 14:27 UTC
Message-ID: <87a615vkqk.fsf@osv.gnss.ru>
In-Reply-To: <CAPMMpogi_QoGKD824JW+85v_Sgaf5d3TAd_P55YyT5NF6AUJ=w@mail.gmail.com>

Tao Klerks <tao@klerks.biz> writes:

> On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> On 18/02/2023 03:17, Elijah Newren wrote:

[...]

Show 19 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.
>>
>
> This is awesome!
>
> It feels like the first step towards the general strategy that was (I
> believe) best described by Buga at
> https://public-inbox.org/git/a0cc88d2-bfed-ce7b-1b3f-3c447d2b32da@gmail.com/
> !

Being the provoker of all the fuss then, as well as the author of basic original method, I agree Buga has summarized and described all the ideas in existence at that time extremely well.

Show 8 quoted lines

>
> (unless I'm missing something, the result of this is exactly the same
> as the result of that strategy, in these "simple" cases where it kicks
> in)
>
> The one concern I have with this is that, *if I understand correctly*,
> it sometimes throws away the existing merge information, and sometimes
> doesn't, and there's no easy way to know which it is at runtime.

As far as I'm aware, it's not the case. The originally described method indeed misbehaved, but this simple mistake has been quickly fixed, and the description by Buga you've referenced already discusses updated version.

> Would adding a warning on stderr when a both-parents merge is
> encountered (and any merge resolutions or related changes are still
> discarded) be enough to make this shippable?

Even if there are in fact such corner cases, we could make ourselves very cautious and stop even after non-conflicting rebase, if we detect that U1' and U2' don't match, and let user decide if the result is acceptable (similar to what rerere does on successful application of replayed resolutions).

I also agree (in particular with Buga) that from the POV of user experience the method suggested by Phillip should be superior, as it emphasizes the natural dominance of the "current branch", as opposed to originally described symmetric method that is more suitable for formal analysis than for actual convenient implementation. Yet creating U1' and U2' from the original method could be useful for the purpose of checking for possible problems with automatic rebase that the user may need to be aware of.

The biggest problem here, as I see it, is designing UI that'd make sense in the case of conflicts in multiple stages of the suggested algorithms, but I think we can simplify it for now by stopping and suggesting blind re-merge in case of any conflict but that on rebasing of changes to the first parent. Even this would be a huge step forward compared to silent drop of merge commits and blindly re-merging of updated parents.

>
> Are there *any* circumstances where the new cherry-picking behavior
> introduced here wouldn't be the right thing to have happen?

None that I'm aware off, but I admit I'm not familiar with later Elijah work on the subject, so I could be mistaken. I only got a sketchy look at what Elijah did, and it looks like advanced material to me. I'd incline to rather get solid implementation of basics first, probably using Phillip method, then consider advanced methods if practice reveals demands for further improvements.

I'm afraid that there is no ideal general solution for the problem of rebasing merge commits, so we need to limit ourselves and get a practical one that has already been described.

Overall, I'd love to finally have reliable Git behavior when rebasing merge commits, even though I've already got a habit to perform all the merges in 2 steps: auto-merge resolving textual conflicts only (if any), followed by a fixup for semantics conflicts (if any).

Thanks, -- Sergey Organov