Re: [PATCH v2 0/3] Teach fetch and pull to recursively fetch submodules too

[Jonathan Nieder <jrnieder@gmail.com>]

Jens Lehmann wrote:
> Am 09.10.2010 22:02, schrieb Jonathan Nieder:
>> Jens Lehmann wrote:

>>>                  And configuring that via .gitmodules has the advantage
>>> that every clone inherits that setting
>> 
>> I certainly do _not_ want that property.
[...]
> Ok, I take that as a vote to remove the parsing of .gitmodules in patch
> 2/3. But I assume you are fine with being able to configure that for
> each submodule via .git/config?

I've lost track of the thread, unfortunately.

But here are my thoughts, quickly:

The place of .gitmodules
------------------------
I think of .gitmodules as a place where upstream places information
about the submodules contained in a repository, what they are about,
and how to get them.  So ideally it would look like this:

	[submodule "gnulib"]
		path = lib/gnulib
		description = GNU Portability Library
		url = ../gnulib.git
		checkout = true

meaning the gnulib is stored at lib/gnulib, can be acquired from
that URL, and needs to be checked out in all but unusual
configurations to build this program.

Already the '[submodule "gnulib"] update' setting goes beyond this
expectation, by including information about policy that has nothing
to do with the superproject.  If we were starting over, I think
"git submodule update" might benefit from being split into two
operations:

	git checkout --recursive

for the update = checkout behavior, and

	git submodule update --pull

for the update = merge/rebase behavior.  The choice between merge and
rebase for the latter would use the usual '[branch "master"] rebase'
configuration, with defaults taken from '[branch] autosetuprebase'.
Maybe a superproject could override that choice in .git/config using
[submodule "foo"] configuration.

Well, it should be obvious by now that I think submodule.<foo>.fetch
does not belong in .gitmodules.

Automatic fetching of submodules
--------------------------------
A '[submodule "<foo>"] fetch' tweakable in .git/config like you
propose makes perfect sense.  But what should the default be?

 1. A conservative answer is "never fetch by default".

 2. A simple but less conservative answer is "fetch the modules
    with checkout = true by default".  (Of course I am not attached to
    the names; this is just a sketch.)

 3. There are other more complicated answers, but I'm a strong
    believer in "keep it simple, especially when the code doesn't
    exist yet".

Hope that helps.