Re: [PATCH 05/15] submodule-config: check if submodule a submodule is in a group
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 26, 2016, 23:17 UTC
- Message-ID
- <xmqqvb34arjj.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <xmqq37q8c6zz.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> I see room for bikeshedding here, but the material to bikeshed > around is not even documented yet ;-) > > * a token prefixed with '*' is a label. > * a token prefixed with './' is a path. > * a token prefixed with ':' is a name. > > Hopefully I will see some description like that in later patches. > I'll read on.
Extending this on a bit, I would suggest tweaking the above slightly and make the rule more like this:
* a token prefixed with '*' is a label.
* a token prefixed with ':' is a name.
* everything else is a path, but "./" at the front is skipped,
which can be used to disambiguate an unfortunate path that
begins with ':' or '*'.A bigger thing I am wondering is if it is bettter to do _without_ adding a new --group=X option everywhere. I am assuming that most if not all submodule subcommands already use "module_list" aka "submodule--helper list" that takes paths, and to them, extending that interface to also understand the groups and names would be a more natural way to extend the UI, no? e.g.
$ git submodule update -- 'path1' 'path2'
$ git submodule update -- '*default'
$ git submodule update -- ':named'instead of
$ git submodule update -- 'path1 'path2'
$ git submodule update --group='*default' --
$ git submodule update --group=':named' --which special-cases the way to specify a set of submodules by listing their paths.