Re: [PATCH/RFC] Pinning of submodules

From: Jens Lehmann <jens.lehmann@web.de>
Date: Sep 7, 2015, 20:13 UTC
Message-ID: <55EDEFDC.3040605@web.de>
In-Reply-To: <CAPig+cRwAjTF6_rT8+nhbsZTYcZqneWSZ_LTCo9z2m5+SEGwWg@mail.gmail.com>

Am 07.09.2015 um 01:43 schrieb Eric Sunshine:

Show 30 quoted lines

> On Sun, Sep 6, 2015 at 6:08 PM, Anders Ro <anders.ronnbrant@gmail.com> wrote:
>> On 04/09/15 07:02, Eric Sunshine wrote:
>>> On Wed, Sep 2, 2015 at 7:34 PM, Anders Ro <anders.ronnbrant@gmail.com> wrote:
>>>> git-submodule.sh: pin submodule when branch name is '@'
>>>>
>>>> Setting branch name to '@' for a submodule will disable 'git submodule
>>>> update --remote' calls for that specific submodule. I.e. instead of
>>>> follow the unspecified default choice of master, nothing is being
>>>> updated. This is useful when multiple submodules exist but not all
>>>> should follow the remote branch head.
>>>
>>> With the disclaimer that I'm not a submodule user (to which the
>>> answer might be obvious): What benefit is there in using a magic
>>> value like this ("@") over, say, an explicit configuration setting?
>>
>>  From what I have understood (not a submodule expert yet) the '@' is an
>> invalid branch name and should therefore not collide with any current
>> branches. My idea was to disable the '--remote' option when the user
>> have explicitly set an invalid branch name to not modify any current
>> behaviour. Though having an explicit option is of course more
>> clarifying. The current behaviour though is that empty branch name means
>> "follow master" which is somewhat unintuitive.
>
> My concern in asking was that some future person might come up with
> another scenario which also wants to use a "magic value" and would
> have to invent / arrive at another "illegal" representation. Hence, an
> explicit setting might be more appropriate. However, as stated, I
> don't even use submodules, so I may be far off the mark. I've cc'd a
> few of the submodule maintainers with the hope that they will chime
> in.

Added Trevor to the CC, who is the original author of --remote (see 06b1abb5b).

While I believe that adding such functionality makes perfect sense, I do not find it terribly obvious that setting the branch to '@' will make --remote skip this submodule. I wouldn't care so much if we'd only use this value internally, but this is user visible (and has to be set by the user if she wants to skip a submodule in --remote).

Setting the branch to an empty value feels a bit more natural, but I'm not so sure our config handling supports that well (we seem to assume in quite some places that empty equals unset). So I tend to prefer a new option for that.