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

From: Johan Herland <johan@herland.net>
Date: Jun 12, 2010, 10:12 UTC
Message-ID: <201006121212.50545.johan@herland.net>
In-Reply-To: <cover.1276059473.git.hvoigt@hvoigt.net>

On Friday 11 June 2010, Heiko Voigt wrote:

> The following patch series is a work in progress. The idea is whenever
> you need to merge two SHA1's of a submodule we search for a ref in the
> submodule which already contains both. If one such ref exists the
> resulting SHA1 is the one pointed at by that ref.

I appreciate the effort to improve submodule handling, but I'm not sure I like this approach. Even though you try to apply it as conservatively as possible, it still smells a little like trying to make Git too clever for its own good.

E.g. say we have the following commit history in the submodule:

  A---B---C---D  <-- master

Now, say that your merge conflict comes from one branch updating the submodule from B to C, while the other branch reverts the submodule from B to A. In your proposed scheme, Git would auto-resolve the conflict to D.

In this case Git has no way of knowing whether the update from B to C is "better" than the revert from B to A. Maybe the revert to A happened because there is a showstopper bug in B that has not yet been fixed, and the best solution is to revert to A until a fix can be made. Or maybe C fixes that showstopper bug, so C is safe after all.

In any case, fast-forwarding to D seems irresponsible, since we have no concept of how well D is tested. Maybe it introduces another showstopper bug, and that is why neither branch has upgraded to it yet?

This whole idea is somewhat similar to branch-tracking submodules (recently discussed in another thread), except that it only applies on _merge_ in the superproject, and you don't get to choose _which_ branch it's tracking. That's _way_ too arbitrary for my tastes.

> The implementation currently searches through all refs and if one (and
> only one) ref exists which contains both sides it merges. In all other
> cases it fails.

Still doesn't solve the fundamental A---B---C---D problem I demonstrated above.

> Future Plans:
> 
>   * Only search stable branches. E.g. by default only master and
>     */master. The stable branch list will be configurable.

What is this "stable" branch of which you speak? "Stable" is a very relative concept, depending on which repo you're working in, and which branch you're working on. In any case, master is often not the most stable branch in a given repo. In git.git for example, maint is more stable than master. Also, I have many repos where master should not be considered "stable" at all...

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net