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: Sun, 26 Feb 2023 12:29:45 +0300 [thread overview]
Message-ID: <87lekklqpi.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CABPp-BF3JUg4jThS8Y_3v-tOEey55V_9KpXRZ3HvfaC3S2m=GQ@mail.gmail.com> (Elijah Newren's message of "Sat, 25 Feb 2023 08:28:49 -0800")
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:
"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, and we just need to
avoid driving ourselves into nested merge conflicts, as resolving them
is beyond capabilities of most human beings.
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.
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?
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2023-02-26 9:29 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 [this message]
2023-02-27 15:20 ` Elijah Newren
2023-02-27 17:17 ` Sergey Organov
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=87lekklqpi.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