From: Jens Lehmann <Jens.Lehmann@web.de>
To: Eric Sunshine <sunshine@sunshineco.com>,
Anders Ro <anders.ronnbrant@gmail.com>
Cc: Git List <git@vger.kernel.org>, Heiko Voigt <hvoigt@hvoigt.net>,
Johan Herland <johan@herland.net>,
Mark Levedahl <mlevedahl@gmail.com>,
"W. Trevor King" <wking@tremily.us>
Subject: Re: [PATCH/RFC] Pinning of submodules
Date: Mon, 7 Sep 2015 22:13:16 +0200 [thread overview]
Message-ID: <55EDEFDC.3040605@web.de> (raw)
In-Reply-To: <CAPig+cRwAjTF6_rT8+nhbsZTYcZqneWSZ_LTCo9z2m5+SEGwWg@mail.gmail.com>
Am 07.09.2015 um 01:43 schrieb Eric Sunshine:
> 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.
next prev parent reply other threads:[~2015-09-07 20:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55E78522.1030107@gmail.com>
2015-09-02 23:34 ` [PATCH/RFC] Pinning of submodules Anders Ro
2015-09-04 5:02 ` Eric Sunshine
2015-09-06 22:08 ` Anders Ro
2015-09-06 23:43 ` Eric Sunshine
2015-09-07 20:13 ` Jens Lehmann [this message]
2015-09-07 23:27 ` Anders Ro
2015-09-08 16:55 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55EDEFDC.3040605@web.de \
--to=jens.lehmann@web.de \
--cc=anders.ronnbrant@gmail.com \
--cc=git@vger.kernel.org \
--cc=hvoigt@hvoigt.net \
--cc=johan@herland.net \
--cc=mlevedahl@gmail.com \
--cc=sunshine@sunshineco.com \
--cc=wking@tremily.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).