Johan Herland <johan@xxxxxxxxxxx> writes: > I still don't like this, as IMHO it's too subtle, and possibly conflicts > with explicitly tracking submodule branches (which, to me, is a more > important feature). If you mean, by "explicitly tracking", to say "I don't care which commit from the submodule appears at this path, as long as it is at the tip of this branch", I still don't think it makes much sense, but what I outlined is not _incompatible_ with such a scheme. In fact I think it would rather fit naturally as a sanity/safety measure. I presume that in your "explicitly tracked" world, if the user tries to commit at the superproject level with a submodule commit that is inconsistent with that "explicitly tracked" branch (e.g. the commit is not reachable from the tip of that branch), you would issue a warning of some sort, using that knowledge. What I outlined uses the exact same knowledge of which branch in the submodule the superproject branch is tied to to reject irrelevant existing merges as resolution candidates. Of course, this ".gitmodule in superproject can tell you which branch of submodule it follows" is optional; the user needs to take responsibility of picking the right one among I, E and G, of course, if the information does not exist or is not available. -- 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