On Monday 21 June 2010, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > >> For an "automated" heuristics based on "find common descendants" to > >> make sense, the branches you are merging have to share the common > >> purpose, and you need to limit the common descendants you find to the > >> ones that are compatible with the shared purpose. The purpose of > >> 'maintenance track' may be to maintain the previous version without > >> dragging newer and more exciting things that happened in the later > >> development. In the above picture, G (that has nothing but B and F) > >> is the only commit that can be safely assumed that two commits in the > >> superproject space that bind B and F respectively can use as the > >> submodule as their merge result. E and I are contaminated with D and > >> H whose purpose in the superproject space is unknown without further > >> hint. > > > > Yes, from a 'maint'-perspective, using G in the superproject probably > > makes more sense than using E or I. From a different superproject > > perspective, though, using E or I might make more sense. > > Actually, what I was alluding to was that 'G' would be the _only_ commit > that may make sense (note that G may not necessarily make sense, but the > point is that we can say that others do _not_ make sense as alternatives) > if we know that the context of making the superproject merge is that it > is doing the 'maintenance track' merge. Similarly, if we know that the > merge being done in the superproject is in the 'master' context, 'E' > would be the _only_ plausible candidate, similarly for 'I' in 'next' > context. Ah, so Git should automatically _eliminate_ other alternatives based on the fact that they are not compatible with the purpose of the superproject merge. Still, that requires Git to know the purpose of the superproject merge. Which it doesn't, AFAICS. > It is further plausible to imagine that the .gitmodules file tracked in > the superproject's 'maint' branch can be used to express that 'maint' > branch of the submodule should be used. Ok, so you want to create some kind of relationship between the superproject's 'maint' branch and the submodule's 'maint' branch. At this point we're almost back to the (magic IMHO) "stable" branch setting that Heiko alluded to in his initial patch series. Except, possibly, that instead of using the tip of that branch you'd use the first merge of B and F on that branch. 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). Or are you talking about outright tracking submodule branches (as proposed by Ævar in a different thread)? In that case, the issue changes completely: If you're explicitly tracking the 'maint' branch in the submodule, then IMHO Git should always propose the tip of the submodule's 'maint' branch as the merge resolution in the superproject (possibly with a warning printed if that tip does not descend from both B and F). > If we revisit the Alice and Bob example with such an arrangement, if they > were working on their branches so that their results would be included in > the 'maint' track of the superproject, there won't be a merge conflict in > the .gitmodules file at the superproject level when their branch tips are > merged; we will know that the merged .gitmodules file will tell us that > we would want to follow 'maint' branch of the submodule. > > Similarly if Alice were fixing a bug in 'maint' but Bob were advancing > features in 'master', then merging .gitmodules at the superproject level > will fast-forward at the path level (i.e. Alice didn't touch, but Bob > changed, so we take Bob's change), instructing us to follow 'master' > branch from the submodule automatically. Ok, so these are similar to Ævar's proposal (and its subsequent discussion) for explicitly tracking submodule branches. Still not sure if we're actually talking about the same thing, though. ...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