Re: [PATCH] submodule merge support

Martin Waitz wrote:

On Sun, May 06, 2007 at 03:18:53PM -0700, Linus Torvalds wrote:

quoted

On Mon, 7 May 2007, Alex Riesen wrote:

quoted

How about making all existing strategies just ignore submodules, and
move recursive merge in the merge driver (git-merge.sh)?

Yes, I think that's the right thing to do.

I think it's the right thing for another reason: in a true "recursive"
merge, the submodules shouldn't be recursively merged anyway. *THEIR*
merge will have its own history, and doing it based on some random history
of the superproject is actually wrong anyway!

Of course the submodule has to get its own history, it's not possible
to do otherwise.  But you have to trigger the submodule merge when you
find a submodule-level conflict in the supermodule merge, just as
you trigger file-level three-way merges, too.

I think you missed Linus's point: If the supermodule's merge leads to a
conflict in the submodule links, it is not appropriate to merge the
submodule.

Say you are merging commits A and B in the supermodule, and A uses v1.0
of the submodule and B uses v2.0 of submodule, then you can't just merge
v1.0 and v2.0 - instead, you have to make a decision whether the
supermodule's merge result is going to use v1.0 or v2.0 or even
something different like v2.1. An automatic merge cannot make this
decision for you (unless there was no conflict in the first place).

-- Hannes