On Mon, 7 May 2007, Johannes Sixt wrote: > > I think you missed Linus's point: If the supermodule's merge leads to a > conflict in the submodule links, it is not appropriate to merge the > submodule. That is true, but no, that wasn't what I was trying to say. What I was trying to say was really that the merge-base in the super-module is simply totally irrelevant to the sub-module, and any merge at all that thinks it is is obviously broken. Now, for a _normal_ merge (with just a single merge-base), this is not an issue, since the proposed submodule merger wouldn't care about the supermodule merge base anyway. But if you have multiple merge-bases and you do a recursive merge to create a new *combined* merge-base, trying to do that for the submodule is just pointless. You shouldn't. The merge-base for the submodule will be irrelevant for the final merge *anyway* (since the submodule history comes from itself), so in a recursive sub-merge, you shouldn't even *try* to merge the submodule. The end result would never be used anyway, and the only thing you can do is make for more complexity. So not doing it in the low-level merger is right - because it is simply irrelevant at that stage. The low-level merger might as well ignore submodules. I think. Linus - 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