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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 22, 2010, 04:04 UTC
Message-ID: <7vmxung1bk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201006220035.31166.johan@herland.net>

Johan Herland <johan@herland.net> writes:

> True, but as I've argued above, I'm not sure that adding another setting 
> (aka. .merge_branch) for this special/limited kind of branch tracking is 
> worth it.

I don't think .merge_branch is necessary nor even desired. In fact, I think your use of .branch, especially in the variant that does not have any submodule entry in the superproject tree, of your version (B) does not have conceptual advantage. You checkout the superproject first (which would be the natural thing to do, as you may get update to its .gitmodules there), and checkout the then-tip of the named branch of the submodule, you would immediately get a stale checkout when you then go fetch the updates to the submodule.

And the worst part is that you wouldn't even _notice_ that your checkout is stale, as there is no record in the superproject which commit you were supposed to be using to be consistent with the version the committer of the superproject commit used to record it.

I on the other hand think what you called "hybrid" makes sense (and I don't even think it is hybrid but rather is a natural way to do this). With the submodule.*.branch entry, you can:

 - make sure that your checkout is consistent; if your submodule checks
   out a different commit or branch from what the superproject records in
   its tree or in its .gitmodules (e.g. you forgot to update the submodule
   when you switched superproject branch), git can notice the situation
   and can help you implement policy decisions;

 - record a commit that is different from the tip of the submodule branch
   when making a superproject commit; git can notice the situation and can
   help you implement policy decisions (e.g. you could choose to reject
   and tell the user to advance the submodule branch first before making
   the commit in the superproject);

 - use it as an advisory "existing merge commit selector", as discussed in
   this thread.

Thinking about what would happen in your (B) that doesn't record the exact commit, I think that it doesn't have any advantage over the "hybrid" one. The "hybrid" one can help you to make sure that what you commit in the superproject's .gitmodules and submodule's branch tip are kept consistent. When they are kept consistent, then switching branches in the superproject should always flip between the tips of branches, no?