On Friday 11 June 2010, Heiko Voigt wrote: > The following patch series is a work in progress. The idea is whenever > you need to merge two SHA1's of a submodule we search for a ref in the > submodule which already contains both. If one such ref exists the > resulting SHA1 is the one pointed at by that ref. I appreciate the effort to improve submodule handling, but I'm not sure I like this approach. Even though you try to apply it as conservatively as possible, it still smells a little like trying to make Git too clever for its own good. E.g. say we have the following commit history in the submodule: A---B---C---D <-- master Now, say that your merge conflict comes from one branch updating the submodule from B to C, while the other branch reverts the submodule from B to A. In your proposed scheme, Git would auto-resolve the conflict to D. In this case Git has no way of knowing whether the update from B to C is "better" than the revert from B to A. Maybe the revert to A happened because there is a showstopper bug in B that has not yet been fixed, and the best solution is to revert to A until a fix can be made. Or maybe C fixes that showstopper bug, so C is safe after all. In any case, fast-forwarding to D seems irresponsible, since we have no concept of how well D is tested. Maybe it introduces another showstopper bug, and that is why neither branch has upgraded to it yet? This whole idea is somewhat similar to branch-tracking submodules (recently discussed in another thread), except that it only applies on _merge_ in the superproject, and you don't get to choose _which_ branch it's tracking. That's _way_ too arbitrary for my tastes. > The implementation currently searches through all refs and if one (and > only one) ref exists which contains both sides it merges. In all other > cases it fails. Still doesn't solve the fundamental A---B---C---D problem I demonstrated above. > Future Plans: > > * Only search stable branches. E.g. by default only master and > */master. The stable branch list will be configurable. What is this "stable" branch of which you speak? "Stable" is a very relative concept, depending on which repo you're working in, and which branch you're working on. In any case, master is often not the most stable branch in a given repo. In git.git for example, maint is more stable than master. Also, I have many repos where master should not be considered "stable" at all... ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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