Jens Lehmann wrote: > No, I think these concepts aren't conflated at all: > > - Category A is handled by .git/config > > - Category B is handled by the .gitmodules file I meant that the two files currently support the same submodule.* options. > There are people putting lots of large files in submodules for better > performance and they almost always never want to fetch (or even stat) > them, so (1) is for them and it's cool that their upstream can configure > that, avoiding to have every developer to repeat their "obvious" choice > after each clone again (and that might only be needed for some submodules, > so a repo-wide config doesn't necessarily help them). Wouldn't (3) work for these people, too? I think we are getting closer to an explanation. I can look into adding documentation for this on top when finished. > And when you are on a superproject branch actively developing inside a > submodule, you may want to increase fetch-activity to fetch all new > commits in the submodule even if they aren't referenced in the > superproject (yet), as that might be just what your fellow developers > are about to do. And the person setting up that branch could do that > once for all users so they don't have to repeat it in every clone. This one seems less reasonable to me. It seems like a way to remotely help developers get a nice setup, rather than a declaration about the content. Let me take an unrelated example to illustrate what I mean. Some projects might want all their developers to use branch.autosetuprebase, to avoid confusion since the update hook is going to reject mergy history anyway. That seems like a perfectly reasonable desire to me, and I'd encourage them to add a script that sets everything up following the policies of their project. Now git could even learn to read a .gitconfig file including settings like that one that do not have a security impact. It would make lots of people happy, and individuals could override settings they really dislike in ~/.gitconfig. Should we do it? I think no, for reasons of intuitiveness and predictability. On the other hand, scenarios like (1) might mean we have to support such things despite that downside. > And > when switching away from that branch all those developers cannot forget > to reconfigure to fetch-on-demand, so not having that in .git/config is > a plus here too. Yes, the "read .gitmodules first and then .git/config" is a very nice enhancement --- thanks! > You have no other choice for hooks because of security concerns. But I > can't see any downsides in leaving upstream *the choice* to configure > default submodule behavior. Lots of people - including me - want that for > clone and checkout. There is one setting that it is obvious to me for upstream should be able to set: "these submodules are a necessary part of the project; always (at clone time, fetch time, checkout, etc) make sure they are available" I could easily be convinced about others, but there ought to be a use case to outweigh the "subtle behavior changing behind my back" syndrome. And again: thanks for doing all this work. It's inspiring. (Next step recursive push?) Jonathan -- 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