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

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 24, 2023, 22:06 UTC
Message-ID: <87bklilnvp.fsf@osv.gnss.ru>
In-Reply-To: <CABPp-BH2XPB4BN5Oo=VnLav_wvAGGUAyZC4HRHRRmES5k75P1Q@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 27 quoted lines

> On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> 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:
>
> [...]
>
>> 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.
>
> I'm not so sure it's a huge step forward.  Or even a step forward.

Git currently throws away my precious merges! Silently! How it's not a step forward to stop doing this?! Sorry for getting that heated :)

Git is well-known for being extremely careful with user content, and there is the only case where it fails miserably: rebasing merges. The above method will simply fix this long-standing deficiency that is even more dangerous as users do trust Git so much.

I can only tell that I, for example, will definitely benefit a lot once it is implemented, as currently a rebase containing merge is at roughly the same level of risk as "cvs update" was in the old days: run and keep your fingers crossed. Well, with Git it's unless you are careful to do 2-step merge-fixup thingy every time you merge, that is basically just poor man attempt at fighting long-standing Git weakness.

Show 6 quoted lines

> Dscho actually implemented the old proposals and tried them out, as
> mentioned in the threads I linked to.  The results on balance were
> significantly worse to him than just throwing away the previous merge
> resolution information and redoing the merge from scratch.  He really
> wanted a better solution, but the previous proposals didn't provide
> it.

OTOH, Buga has sketched the proposals, confirmed problem with my
original one (that Dscho predicted), then sketched the update I came up
with, and showed it does work in common cases as expected.
 
That said, I'm almost sure that for any method of rebasing and/or
merging of whatever, one motivated enough will be able to find corner
cases where the method fails, yet we do have both merges and rebases in
Git, and rebasing of merges falls to the same category. We need them.
Merges need to be properly rebased, not silently replaced with
(different) merges, unless user asks for re-merge explicitly. To me
Dscho (or anybody else) finding rough cases is an expected outcome, and
is not a convincing argument against the feature.

As for Dscho results specifically, I've got an impression that he never needed rebasing of merges in the first place, and re-merging always suited him just fine, so it'd be rather a surprise if rebasing of merges suddenly started to work better for his needs and workflows once he has implemented it.

That said, when better method(s) of rebasing of merges will be found, I'm sure they'll be adopted, but for now I do believe we need something reliable that has been checked to actually work for common cases, as blind re-merging simply does not, and I still suspect the best choice for the time being is Phillip's incremental method.

Overall, I'm still in desperate need for my precious merge-the-commits be rebased, and not replaced with Git idea of how merge commit would look if [current version of] 'git-merge' algorithm merged my branch in [using Git current default settings]. It's my dream that Git finally stops silently substituting a result of 'git-merge' (just-a-helper-operation intended to simplify creation of merge commits) for actual merge-the-commit that is part of my content.

Best regards, -- Sergey Organov