From: Junio C Hamano Date: Tue, 29 Jul 2008 14:53:08 GMT Subject: Re: git submodules Message-ID: <7v7ib4ivxn.fsf@gitster.siamese.dyndns.org> In-Reply-To: <320075ff0807290631l1f9a1e70jcb73bde7e2c86000@mail.gmail.com> "Nigel Magnay" writes: >> 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).