On 07/09/15 22:13, Jens Lehmann wrote:
> Am 07.09.2015 um 01:43 schrieb Eric Sunshine:
>> On Sun, Sep 6, 2015 at 6:08 PM, Anders Ro <anders.ronnbrant@xxxxxxxxx>
>> wrote:
>>> On 04/09/15 07:02, Eric Sunshine wrote:
>>>> On Wed, Sep 2, 2015 at 7:34 PM, Anders Ro
>>>> <anders.ronnbrant@xxxxxxxxx> 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.
Agree this is not a "future proof" solution. Though faily a quick one. I
started with a setting but realized it involved a bit more changes since
you should be able to tell the submodule command to pin a submodule
right from the start etc.
>
> 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.
I started out that way, thinking that would solve my initial problem of
having 4 submodules which should follow branch 'develop' and one
submodule that should stay put until explicitly changed. Instead having
empty an branch name gave me 'master' on that module, which was way off
current status of the code to say the least. This was all executed by
Jenkins which either gives you "update remote branches" or "not update
remote branches". Thus no other choice than to change the code.
The current 'git submodule add' takes option '-b' as branch and last
time I tried providing '@' as branch name it did not work. That
indicates that there should be a '-p' option for pinning the submodule
from the start. Having to fiddle with the .gitmodules file after the
fact is not really user friendly (though it have worked for me for a
while). I will have a go at an explicit setting in a week or two and get
back for comments on that. Perhaps some maintainers can give some hints
on adding a new option etc meanwhile. How about option '-p, ---pinned'
and setting 'submodule.<branch>.pinned = true|false'?
Cleaned-up the test code according to Eric's comments, looks a bit more
stylish actually :).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html