Johan Herland <johan@xxxxxxxxxxx> writes: > On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > ... >> That "backing out" can be made more intelligently than just dying >> with "compare and swap failed--please retry" message, e.g. you at >> that point notice what you started with, what the other party did >> while you were working on (i.e. updating refs/tags/), and three-way >> merge the refs tree, and in cases where "all refs recorded as loose >> refs" scheme wouldn't have resulted in problematic conflict, such a >> three-way merge would resolve trivially (you updated refs/heads/ and >> the update by the other process to refs/tags/ would not conflict >> with what you did). But the same three-way merge scheme can be >> employed with the current flat single packed-refs scheme, can't it? > > Yes. (albeit without reusing the machinery we already have for doing > three-way merges) I do not think that is relevant, as you do *not* want to reuse the usual three-way xdiff merge machinery that leaves "<=>" markers for this usage anyway. But that is not the primary reason why I am beating this dead horse; it is the following. Your version of packed-refs file, and his version of packed-refs file, and the original you started with, are all sorted in a known order. You just look at lines from all and merge them line by line. I think that logic should become a new blob-level merge driver that can be reused for normal in-working-tree objects that are sorted. For that kind of "sorted wordlist" file, conflicts that may artificially arise only because two sides updated adjacent lines in the list and you used the normal xdiff merge machinery is unwanted, and users would benefit by having such a specialized merge driver outside the context of merging two proposed list of refs. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html