Re: [WIP PATCH 0/3] implement merge strategy for submodule links

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 21, 2010, 00:03 UTC
Message-ID: <7vk4pttfo3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201006210106.07758.johan@herland.net>

Johan Herland <johan@herland.net> writes:

Show 15 quoted lines

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

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.

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.