On Tue, Apr 26, 2016 at 4:17 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> 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. This is indeed a better way. Currently there is no way to initialize another group as that group specified by submodule.defaultGroup. But having the possibility to use the grouping in such a way is more flexible. Thanks, Stefan -- 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