Re: [PATCH 00/19] Cleanup merge API

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 25, 2019, 19:15 UTC
Message-ID: <nycvar.QRO.7.76.6.1907252055500.21907@tvgsbejvaqbjf.bet>
In-Reply-To: <20190725174611.14802-1-newren@gmail.com>

Hi Elijah,

On Thu, 25 Jul 2019, Elijah Newren wrote:

Show 6 quoted lines

>   * All current callers (3 of them?) of merge_recursive() always pass
>     it a specially created reversed-list for the merge_bases.  Some
>     history spelunking provides no details on any of these about why;
>     it appears that the 2nd and 3rd callers reversed the list because
>     the first did, and I'm guessing the first did in an attempt to
>     exactly match the git-merge-recursive.py scripts' behavior.

That is part of the reason.

After I worked on converting that Python script with Alex Riesen, I tested it on all merge commits I could find at that point in linux.git, to compare the outcomes between scripted and non-scripted versions. IIRC I even reported those findings back to the mailing list.

*clickety-click*

Ah, I did the extensive test on git.git first [*1*]: https://public-inbox.org/git/Pine.LNX.4.63.0608092232000.13885@wbgn013.biozentrum.uni-wuerzburg.de/

As you can see, it seemed that the reverse order of merge bases (trying to merge the oldest two merge bases first, then merging with the 3rd-oldest, etc) avoided more merge conflicts than the original order.

>     But if the API needs them in a reverse order from what people
>     would normally expect to pass them in, shouldn't it reverse them
>     itself instead of making all callers do it?

I would not, as the order the merge bases are passed in defines the order in which they are handled.

>     Also, the order shouldn't matter when there are no conflicts, and
>     when there are conflicts it'd only change which side of the
>     conflict markers the made-up virtual merge base would list things
>     in.

That's what I thought, right up until I re-created those merge commits.

I really forgot most of the details, but I seem to remember that there was a puzzling one where the reverse order caused no merge conflicts, and the original order caused a double merge conflict.

Show 6 quoted lines

>     However, we do have tests with recursive virtual merge bases
>     and which test the output, and I didn't want to try to clean those
>     all up.  Besides, the current order shows nicely when commits are
>     named things like "L1", "L2", "R1", "R2" -- it's nice having a
>     well defined left and right side.  Wasn't sure what to do yet, so
>     I just punted for now; this series is already long enough...

Good. I think you would have entered an unpleasant space if you had run down that rabbit hole ;-)

Ciao, Dscho

Footnote *1*: I did remember correctly, though, that I re-created all merge commits of then-current linux.git: https://public-inbox.org/git/Pine.LNX.4.63.0608131550290.10541@wbgn013.biozentrum.uni-wuerzburg.de/