Re: RFC: Making submodules "track" branches

Am 08.06.2010 09:12, schrieb Johan Herland:

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

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

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