Jeff King <peff@xxxxxxxx> writes: >> With "natively" do you mean some internal state that is never written >> into the index? If this were the case then there wouldn't be any >> problem with the restriction when reading the index file. > > FWIW, that was my question on reading Junio's response, too. The current code may not put two stage #1 entries for the same path but allowing such entries was a part of the design from very early days; iow it is a valid index file, unlike the one that has both stage #0 and stage #1 for the same path. It is a no-no to reject such an index as long as we are discussing to add a new code to tighten the sanity check on the file content. >> I have also tried to reproduce it by directly calling >> git-merge-recursive and the most I have got is what it seemed to be >> like a conflict in the stage #1: >> >> $ git ls-files -s >> 100644 1036ba5101378f06aa10c5fa249b67e14f83166b 1 conflict >> 100644 2638c45f8e7bc5b56f70e92390153572811782c3 2 conflict >> 100644 178481050188cf00d7d9cd5a11e43ab8fab9294f 3 conflict >> >> $ git cat-file blob 1036ba5101378f06aa10c5fa249b67e14f83166b >> <<<<<<< Temporary merge branch 1 >> G >> ======= >> E >> F >> >>>>>>> Temporary merge branch 2 > > Yes, I think merge-recursive resolves the earlier merges and then feeds > the result into the main merge. And that's how you end up with the > "temporary merge branch" name instead of something useful. Yes---that is what I meant by the "virtual stuff". Unlike resolve work by Daniel (around Sep 2005 $gmane/8088) that tried to use multiple ancestors directly in a single merge, recursive limits itself to repeated use of pairwise merges. -- 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