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

[Jonathan Nieder <jrnieder@gmail.com>]

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