Re: git submodules

"Nigel Magnay" [off-list ref] writes:

quoted

I do not understand.  We are talking about three different things here:

1) the committed state of the submodule
2) the local state of the submodule
3) the state of the "tracks" branch

We always have 1) and we have 2) _iff_ the submodule was checked out.  We
only will have 3) if "tracks" is set in .git/config (for consistency's
sake, we should not read that information directly from the .gitmodules
file, but let the user override it in .git/config after "submodule init".

I think the implication is that .gitconfig states "I'm expecting that
submodule X will always be tracking branch name 'Y'" and that you
wouldn't ever override it in .git/config. If you then switched
submodule X to branch Z, then committed the superproject, that commit
would contain a change to .gitconfig also (to say I'm expecting to
track Z rather than X') ?

You are right.  I think letting the user override with .git/config is a
good idea, but it shouldn't be ".gitmodules may say X or whatever, but I
want to use Y".

Instead, it should be more like "On branches where .gitmodules says X, I
want to use Y."

This comment actually applies to the existing override of .gitmodules item
with .git/config (I think I've been saying it since the design phase).