Re: RFC: Making submodules "track" branches

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 8, 2010, 16:06 UTC
Message-ID: <4C0E6A8A.70608@web.de>
In-Reply-To: <201006080912.31448.johan@herland.net>

Am 08.06.2010 09:12, schrieb Johan Herland:

Show 5 quoted lines

> - When switching branches in the superrepo, you sometimes also want to 
> switch branches in the submodule. This is signalled by changing the 
> submodules.subthing.branch variable in .gitmodules between the two branches. 
> However, it means that the submodule's update/pull operation must also be 
> done on 'checkout' in the superrepo.

Hm, I always want the submodules to switch branches along with the super- project (I posted a RFC patch for that), but i can see other people don't want that at all or just for some submodules. But am I wrong assuming that it's either "switch branches in submodules too every time" or "never do that" for a single submodule?

> - How to handle local/uncommitted (staged or unstaged) modifications in a 
> submodule when pulling or switching branches in the superrepo? The right 
> answer here is probably to do the same as in the no-submodule case, i.e. to 
> refuse if it would clobber/conflict with the local modifications.

Yup. I thing one goal for submodules is that they should blend in with the superprojects as far as possible (unless configured to not to).

Show 11 quoted lines

> - When you track submodule branches instead of commits, the actual commit 
> referenced in the superrepo is no longer as important (provided it's part of 
> the ancestry of the submodule branch you're tracking). However, diff/status 
> will still list the submodule as changed because you checked out a different 
> commit from what Git has recorded. This raises two concerns: (1) What 
> _should_ be considered "changed" from the diff/status perspective when 
> tracking submodule branches? and (2) When do you update the commit reference 
> in the submodule? "never" would work (since you're checking out a different 
> commit anyway), "always" would also work (for the same reason), but would 
> litter the superrepo history with submodule updates. There may be a better 
> alternative somewhere in between.

Don't record a commit in the first place, following a branch is not bound to a special commit, so pretending to do that might do more harm than good. Just putting the 0-hash there might be the solution.

Show 6 quoted lines

> - If you want to give the illusion of "one big repo" then maybe it should 
> also be possible to trigger submodule commits from a superrepo commit? (i.e. 
> having a single toplevel "git commit" also trigger commits in submodules). 
> Some users will want to specify the commit message for each submodule 
> separately (IMHO the better approach), while some will want to give only one 
> commit message that is reused in every submodule commit.

Hm, personally I am fine with first committing in the submodules and then in the superproject.