Re: git submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 29, 2008, 14:53 UTC
Message-ID: <7v7ib4ivxn.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <320075ff0807290631l1f9a1e70jcb73bde7e2c86000@mail.gmail.com>

"Nigel Magnay" <nigel.magnay@gmail.com> writes:

Show 17 quoted lines

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