Hi Elijah, On Thu, 25 Jul 2019, Elijah Newren wrote: > * 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 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. > 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
