On Thu, Jan 21, 2016 at 10:56 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >>> [submodule "gcc"] >>> path = gcc >>> url = git://... >>> groups = default >>> groups = devel >> >> On the quick I was unable to find the rationale why entries are now stored as separated lines compared to v1. I liked the comma-separated approach better as it's more compact. > > IIUC the line oriented way is preferred as it is our standard. Do we > have any other options stored as a comma separated list? Out of my head I cannot think of any. But that shouldn't mean we cannot introduce such comma separated list if it makes sense. > Makes sense to use singular then. However per discussion with Junio in > [PATCH 3/4] submodule update: Initialize all group-selected submodules > by default, we want to not name it "group", as it's unclear what a group is > supposed to mean. What does a group do? which operations are supported? How about calling it "label" instead of "group"? IMO with the word "label" it's more clean that a single submodule can have multiple labels, as the concept of labels is familiar to the user already from applications like Firefox (bookmarks), Google Mail, Mac OS X Finder (files) etc. > Instead of having a submodule -> set assignment, we could do it the > other way round: > > [submodule "gcc"] > ... > > [submodule-set "default"] > submodule = gcc > submodule = foo > submodule = by/path/* In your example you're now introducing "set" as a new term. Shouldn't this better be "submodule-group" then? I actually like this idea quite a bit as it completely solves the problem about being clear that a submodule can belong to mutiple groups. > but I'd assume this is less useful for the user. How often does a user ask: > "How many/Which submodules are in $GROUP" as opposed to "What about > submodule foo, > is that part of group $GROUP?" True, but for answering that question a user would not look at .gitmodules, but run a command, and the implementation of that command would completely hide that complexity from the user. > As asked above, how many comma separated things do we have in git configs? > I'd really not want to add more mental complexity to Git. As far as I I don't think it can get much worse anyway ;-) > remember we have > rather double configs than one long line separated somehow. > (The only thing that comes to mind is multiple remote urls for pushing) I believe so, too. But I'd see the introduction of comma-separated values as an exit-strategy to that. More settings could make use of that in the future, then. -- Sebastian Schuberth -- 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