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. -- 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