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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 21, 2010, 18:29 UTC
Message-ID: <20101021182916.GB11501@burratino>
In-Reply-To: <4CB0D28A.10506@web.de>

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.