On Mon, Mar 12, 2018 at 5:38 PM, Elijah Newren <new...@gmail.com> wrote: > I feel the analogy to merging binary files breaks down here in more > than one way:
Actually, after mulling this over, I'm going to retract the "more than" piece of this sentence. I'm trying to figure out how to retract more, but have only figured out one piece. In particular... > 1) > > Merging binary files is more complex than you suggest here. In > particular, when creating a virtual merge base, the resolution chosen > is not the version of the file from HEAD, but the version of the file > from the merge base. Nasty problems would result otherwise for the > recursive case. > > If we tried to match how merging binary files behaved, we run into the > problem that the colliding file conflict case has no common version of > the file from a merge base. So the same strategy just doesn't apply. > The closest would be outright deleting both versions of the file for > the virtual merge base and punting to the outer merge to deal with it. > That might be okay, but seems really odd to me. I feel like it'd > unnecessarily increase the number of conflicts users will see, though > maybe it wouldn't be horrible if this was only done when the files > were considered dissimilar anyway. Thinking about this more, it really isn't that weird at all. The code is already set up to use null_oid as the "original" version when creating a virtual merge base, going back to the content from a recursive merge base is a strategy used in multiple places in recursive cases, and null is precisely the version from the recursive merge base. If two added files differ wildly, I don't think using null would increase the number of conflicts appreciably, if at all. So, the analogy to merging binary files holds just fine from this angle. So, if we could figure out how to handle the higher numbers of paths for e.g. the rename/rename cases, then perhaps this is a strategy that could work. >> Interesting. I would be tempted to resolve this inconsistency the >> other way: by doing a half-hearted two-way merge (e.g. by picking one >> of the two versions of the colliding file) and marking the path as >> conflicted in the index. That way it's more similar to edit/edit, >> too. > > Your proposal is underspecified; there are more complicated cases > where your wording could have different meanings. > <snip> > My question for your counter-proposal: > Do you record C1 or C2 as C? Or do you record the version of C from > HEAD as C? And what do you pick when creating a virtual merge base? > > Problems I see regardless of the choice in your counter-proposal: > * If you choose C from HEAD, you are ignoring 3 other versions of > "C" (as opposed to just one other version when merging a binary file); > will the user recognize that and know how to look at all four > versions? > * If you choose C1 or C2, the user will see conflict markers; will > the user recognize that this is only a _subset_ of the conflicts, and > that there's a lot of content that was completely ignored? > * There is no "merge base of C1 and C2" to use for the virtual merge > base. What will you use? For this last question, the answer is "null", and it works just fine. I don't yet have good answers to the other questions, though. If someone else does, I'd love to hear it. Oh, and by the way Jonathan, thanks very much for your feedback and alternative ideas for consideration. You gave me more angles to try to think about this problem from.
