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