Am 15.06.2010 01:59, schrieb Johan Herland: > My point is that when Git tries to suggest merge resolutions, it should > purposefully NOT add these to the index, so that the user HAS to acknowledge > them. This is similar to the default behaviour of 'git rerere' which > resolves your conflicts automatically, but does not touch the corresponding > "unmerged" index entries, so that you manually have to 'git add' the result. I like that idea, as it avoids having unintended submodule commits added silently to the superprojects index by the merge. >> Lets assume Alice creates a feature branch feature_a for her development >> and needs to modify the submodule and creates a branch there as well. At >> the same time Bob develops feature_b and also needs changes in the >> submodule and so he creates a feature branch there as well. >> >> Assume we now have the following history in the submodule: >> >> B---C---D [feature_a] >> / \ >> A---E---F---G---K [master] >> \ / >> H---I---J [feature_b] >> >> Now during the development of her branch Alice would link D in the >> superproject as it is the tip of her branch. Bob would do the same and >> link to J as his tip. Now Alice sends out her branch to the reviewers >> and after everybody is happy with it the maintainer merges her branch >> first. The superproject links to D. > > No. The superproject would get a conflict between the A->D and A->F updates > of the submodule. The correct resolution would be to go into the submodule, > do the merge to produce G, and then record this as the correct merge > resolution in the superproject. But as far as I understood this patch this merge has already been done inside the submodule (at least this is what the setup of the test case seems to do at a quick glance). > You want Git to do this automatically for you, whereas I think that Git > should not be that "clever", because there are situations (as I've > demonstrated previously in this thread) where the "cleverness" would do The > Wrong Thing. > >> Now Bob does the same and the >> maintainer wants to merge his branch and gets a merge conflict because D >> and J do not have a parent/children relationship. > > Well, s/D/G/, but your point still stands. And the correct resolution is, of > course, to merge G and J to produce K, and then record K in the superproject > as the correct merge resolution. > > Again, the question is whether Git should do these submodule merges > automatically, or not. Hm, maybe I am missing something here, but isn't the question whether Git should /use/ these submodule merges already done by a human being instead of /doing them itself/? So isn't it just about making Git so clever it proposes a merge already present in the submodule for recording in the superproject when merging there? > Feel free to post the patches, if you can spend the time making them. So > far, there's been no other feedback in this thread, so maybe I'm alone in my > worries... I fully understand your worries concerning automagic merges inside a submodule. But I really would like to see Git assisting me when merging submodule commits in the superproject that have already been merged in the submodule repo. And for me the first commit containing the others is the one I would like to see then. -- 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