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

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 27, 2023, 17:17 UTC
Message-ID: <87pm9v6n9a.fsf@osv.gnss.ru>
In-Reply-To: <CABPp-BGJ+jdwizBNyYr-st58F6BPbyrJ+DwRX81_0NjgU6LhzA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 31 quoted lines

> On Sun, Feb 26, 2023 at 1:29 AM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> > On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov <sorganov@gmail.com> wrote:
>> >>
>> >> Elijah Newren <newren@gmail.com> writes:
>> >>
>> >> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov <sorganov@gmail.com> wrote:
>> >> >>
>> >> >> Elijah Newren <newren@gmail.com> writes:
>> >>
>> >> [...]
>> >>
>> >> > Please, go read at least [1] to see Johannes comments about how the
>> >> > prior proposals don't work beyond simple cases.
>> >>
>> >> It's exactly handling of simple cases that we need most. We can get
>> >> fancy afterwards, if feasible.
>> >
>> > If we can handle just the simple cases without making common cases
>> > significantly worse, that'd be a potential path forward.  Any proposal
>> > involving the diff between a merge commit and either of its parents
>> > (or an equivalent such as a three-way merge involving the merge commit
>> > and one of its parents) doesn't achieve that, IMO.
>>
>> Except the method discussed does achieve exactly that according to the
>> evidence gathered at the time of debates, and here is confirmation (from
>> Johannes himself) from the reference you provided:
>
> I'm glad you read it.  :-)

In fact I didn't read it, I rather re-read it ;-)

(I'm in the CC list there, so it should not have been a surprise I did read it then.)

Show 10 quoted lines

>
>> "This strategy, while it performed well in my initial tests (and in
>> Buga's initial tests, too), *does* involve more than one 3-way merge,
>> and therefore it risks something very, very nasty: *nested* merge
>> conflicts."
>>
>> So, overall, the method performs well in general,
>
> Jumping from "performed well on initial tests" to "performs well in
> general" seems to me to be quite a large and unwarranted logical leap.

There were quite a few tests performed and methods were polished before Johannes has been persuaded to give the feature a try, some of the tests being complex enough, and both methods did perform rather well. That is what he calls "initial tests" there I believe, and then he found the case that is very important to him, but lead him to nested merge conflicts, that is indeed quite bad.

Show 7 quoted lines

>
>> and we just need to avoid driving ourselves into nested merge
>> conflicts
>
> I'm glad you're discussing a disadvantage and how to address it, but I
> don't understand how you can jump to the implication that this is the
> only one.

Well, it was you who gave me the reference to comment on, and that was the only disadvantage I was able to find being discussed there. I also don't recall any other objections back then when the problem has been discussed a lot.

Show 9 quoted lines

>> Setting this back into perspective, in comparison to blind re-merge,
>> that fails to keep user changes even when no conflicts at all exist, and
>> even when it's applied at the same place in the history, the discussed
>> method is a *huge* step forward, especially if re-merge is kept as a
>> fallback strategy.
>
> The use of superlatives and asterisks doesn't change my opinion; I'm
> still skeptical that the given strategy is overall a step forward, let
> alone a large one.

You just repeat saying the same thing, without any further arguments? OK, thank you for your opinion anyway.

> (I do agree we have a huge problem and thus that a huge step forward
> theoretically could be taken, I just don't see this as it.)

It works. Really.

Show 7 quoted lines

>
>> P.S. BTW, where this hate for using of diffs with respect to parents
>> come from, I wonder, provided we do use them all the time anyway?
>
> I have no hate for such diffs; I just firmly believe they are
> inappropriate as a solution for the particular problem space being
> discussed.

From my POV particular problem space (rebasing commits) already uses the diffs, and only them, that's why I can't figure how you end up coming to such conclusion.

>
> But I've stated that more than enough, and no one is producing patches
> on this topic right now, so I'll drop out of this thread.

OK, I participate only in hope that there will be somebody who actually cares enough to implement it. Maybe it will be me, maybe not, and I already got it that neither you nor the original author of git-rebase are interested.

> I still believe in my proposed solution, and I'll implement it as I
> get time for it.

Sure it'd be nice. Fortunately there is nothing mutually exclusive here.

Thanks, -- Sergey Organov