Re: [PATCH v3 2/3] Add the 'fetch.recurseSubmodules' config setting

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 12, 2010, 20:16 UTC
Message-ID: <20101112201640.GB25248@burratino>
In-Reply-To: <4CDD9A02.6000507@web.de>

Jens Lehmann wrote:

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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.

Show 6 quoted lines

> 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