"Ping Yin" <pkufranky@xxxxxxxxx> writes: >> I would agree that allowing the user to use a short-hand to name a group >> of modules the user is interested in would be a good idea, but I think >> .gitmodules is a wrong place to do so. The grouping is a user preference, >> isn't it? >> >> The place the owner of the repository (not the project) expresses which >> modules are of interest, what transports she wants to use to access it, >> etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to >> be used when the user populates that information. >> > Not always the case. In my company environment, we have many > submodules and have a unified hierachy of modules,... > ..., it's better to put the > common config in .gitmodules to pass to every one. I think we are saying the same thing, and I do not understand why you sound so upset about my comments. I never said it is bad to copy the "hints" supplied by .gitmodules verbatim to $GIT_DIR/config. See how the current cmd_init() uses the information in .gitmodules. It could later become interactive to allow users to override what's in there, but by default it simply uses the information from .gitmodules verbatim. In the special case of everybody using exactly the same settings, you can have "all" submodule group alias in .gitmodules, and the user can say "git submodule init all", which would set up the set of the modules the user would work with, using the "hints" in the .gitmodules distributed company wide verbatim. One of the goal of the overall design of submodules is _not forcing_ but still allowing such uniformity, and I think using $GIT_DIR/config as authoritative and treating in-tree .gitmodules as hint to prime $GIT_DIR/config is quite fundamental to that design. Let's make sure we do not needlessly deviate from it. Because names to name things are fundamental part of the communication, I do not think we would want to allow users to call A what the project as a whole calls B. The use of .gitmodules by the current module_name() that maps a specific name to a path is not just fine but is preferred for this reason (i.e. if we copied them to $GIT_DIR/config it would only introduce tower-of-babel confusion). However, a short-hand to name groups of submodules is not just about naming one thing with one name, but has user convenience aspect too. There should be per-user customizability built into the design. You could probably fix this by making the code first consult $GIT_DIR/config and then fall back on in-tree .gitmodules file. By the way, in your patch, I notice that quoting of $name is often very loosely done. I do not think we have officially defined what the allowed repertoire of module name characters are, but we probably should declare the rules and make sure the code actively enforces it to prevent future grief. I'd say the same restriction as we have for refnames, except that we do not allow slashes either, is good enough? -- 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
