On Sunday 20 June 2010, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > On Thursday 17 June 2010, Jens Lehmann wrote: > > ... > > > >> And no 'special' branch is used here. > > > > Well, you need to traverse _some_ submodule ref(s) in order to find 'E' > > at all. My argument is that there may also be _other_ submodule refs > > that contain merges of 'B' and 'F' as well, and they should _also_ be > > considered as valid candidates for the resolution in '5'. I would in > > fact argue that you should traverse _all_ submodule refs (maybe even > > including remote- tracking refs) to look for merges of 'B' and 'F' > > [1], and present them all as equal alternatives. > > > > Consider for example this submodule scenario: > > -----------G [maint] > > / / > > ---B-------- / [feature_a] > > / \ \/ > > A--C---D---E /\ [master] > > \ / / \ > > ----F--- \ [feature_b] > > \ \ > > --H--I--J [next] > > > > If there exist multiple merges that resolve 'B' and 'F' (in this case: > > 'G', 'E' and 'I'), then all of those should be presented as equal > > alternatives to the user. > > You lost me completely here. > > I thought you were going to argue that it would be an utterly wrong thing > to suggest E or I as a probably resolution if the superproject merge that > needs to merge superproject commits that binds B and F as its submodules > is being done in the context of advance 'maint' track of the > superproject. > > Think of 'D' as a commit that corresponds to a major version bump point > of the superproject; i.e. it introduces a major change to the submodule. > In the 'maintenance track' of the superproject for maintaining the > previous version, you don't want to have any commit that has 'D' as an > ancestor. > > 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. If, say, the superproject customarily follows the commits on the 'master' branch in the submodule, but the superproject has not yet gotten around to updating from A to C, D or E, then, by the time we do the superproject merge of Alice and Bob's branches, I would still say that using E is better than using G. My argument is that without knowing the purpose of the superproject merge (which Git by itself _cannot_ know), Git should not prefer _any_ of these merges over the other, but must present them all as equal alternatives to the user. Of course, the user has other alternatives as well, like creating a whole new merge in the submodule, or doing something completely different. But if existing submodule merges are to be considered valid alternatives, Git cannot pretend to know which of those merges are more suitable. It can only present them to the user, and then the user (after having examined the merges and their history relative to B and F) may choose the merge that matches the purpose of the superproject merge. ...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