From: Sergey Organov <sorganov@gmail•com>
To: Elijah Newren <newren@gmail•com>
Cc: Tao Klerks <tao@klerks•biz>,
phillip.wood@dunelm•org.uk, Alex Henrie <alexhenrie24@gmail•com>,
Tao Klerks via GitGitGadget <gitgitgadget@gmail•com>,
git@vger•kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx•de>
Subject: Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"
Date: Mon, 27 Feb 2023 20:17:53 +0300 [thread overview]
Message-ID: <87pm9v6n9a.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CABPp-BGJ+jdwizBNyYr-st58F6BPbyrJ+DwRX81_0NjgU6LhzA@mail.gmail.com> (Elijah Newren's message of "Mon, 27 Feb 2023 07:20:54 -0800")
Elijah Newren <newren@gmail•com> writes:
> 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.)
>
>> "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.
>
>> 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.
>> 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.
>
>> 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
next prev parent reply other threads:[~2023-02-27 17:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-05 16:24 [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true" Tao Klerks via GitGitGadget
2023-02-16 3:22 ` Alex Henrie
2023-02-16 12:31 ` Tao Klerks
2023-02-17 3:15 ` Alex Henrie
2023-02-17 11:15 ` Tao Klerks
2023-02-17 18:56 ` Alex Henrie
2023-02-17 17:39 ` Junio C Hamano
2023-02-18 3:17 ` Elijah Newren
2023-02-18 16:39 ` Phillip Wood
2023-02-20 8:03 ` Tao Klerks
2023-02-20 16:45 ` Phillip Wood
2023-02-20 16:56 ` Elijah Newren
2023-02-21 14:04 ` Tao Klerks
2023-02-22 14:27 ` Sergey Organov
2023-02-24 7:06 ` Elijah Newren
2023-02-24 22:06 ` Sergey Organov
2023-02-24 23:59 ` Elijah Newren
2023-02-25 15:15 ` Sergey Organov
2023-02-25 16:28 ` Elijah Newren
2023-02-26 9:29 ` Sergey Organov
2023-02-27 15:20 ` Elijah Newren
2023-02-27 17:17 ` Sergey Organov [this message]
2023-02-28 2:35 ` Elijah Newren
2023-02-20 16:46 ` Elijah Newren
2023-02-20 6:01 ` Tao Klerks
2023-02-20 17:20 ` Elijah Newren
2023-02-20 18:33 ` Alex Henrie
2023-02-21 15:40 ` Tao Klerks
2023-02-21 17:45 ` Alex Henrie
2023-02-21 15:01 ` Tao Klerks
2023-02-24 7:06 ` Elijah Newren
2023-02-28 14:13 ` Felipe Contreras
2023-02-28 20:04 ` Alex Henrie
2023-03-01 12:46 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pm9v6n9a.fsf@osv.gnss.ru \
--to=sorganov@gmail$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=alexhenrie24@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=newren@gmail$(echo .)com \
--cc=phillip.wood@dunelm$(echo .)org.uk \
--cc=tao@klerks$(echo .)biz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox