Re: [1.8.0] Don't copy "submodule.<name>.update" to .git/config on submodule init

From: Jens Lehmann <jens.lehmann@web.de>
Date: Feb 23, 2011, 22:43 UTC
Message-ID: <4D658D8F.2040203@web.de>
In-Reply-To: <7v7hcq8pil.fsf@alter.siamese.dyndns.org>

Am 23.02.2011 21:28, schrieb Junio C Hamano:

Show 14 quoted lines

> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
>> Proposal:
>>
>> Stop copying the "submodule.<name>.update" entries into .git/config
>> on "git submodule init". The current behavior makes it impossible
>> for upstream to change defaults later, as this value can only be
>> altered through user intervention when it resides in .git/config.
>> This is a good thing when he chose to copy it there, but it doesn't
>> seem to make much sense doing it by default.
> 
> Doesn't it just come from the usual "upstream can give a sane default as
> recommendation to users who may not bother to set up .git/config, and the
> user can tweak that if that doesn't suit his/her needs" convention?

Yup, but when *copying* it locally upstream won't be able to change that default ever again. Wouldn't it suffice to copy that *only* if the user really wants to tweak it?

And now I read that again I notice that I forgot to add a very important sentence, sorry about that:

"Take the setting from .gitmodules if submodule.<name>.update is not configured by the user in .git/config."

> I have a feeling that the correct fix (not limited to "update" but all the
> submodule related configuration that share the same "give default, allow
> tweak" philosophy) is to:

I agree that all should behave the same way for consistency reasons.

Show 16 quoted lines

>  (1) record submodule.<name>.update at initialization time, to allow the
>      upstream a chance to give a sensible default, as we do now;
> 
>  (2) in addition to that, record the fact that the value came as upstream
>      default.  You could do so in multiple ways:
> 
>      a) record the commit that gave the suggested default to .git/config,
>      perhaps submodule.<name>.defaultedFrom (notice that this is
>      independent from "update", and covers all such configuration
>      variables with a single value); or
> 
>      b) record the value the upstream gave to .git/config in a separate
>      variable, perhaps submodule.<name>.updateSuggested; or
> 
>      c) some other clever way you can think of, as long as it lets us do
>      the next step.

My proposal uses the values in .gitmodules for those proposed by upstream and those in .git/config as those tweaked by the user. Isn't that simpler than 1) and 2) while giving us the same functionality? And additionally it is not setting the upstream default in stone (which is rather arbitrary as it just happened to be present in our .gitmodules when we did the "git submodule init" and might be different at another point in the history)?

Show 17 quoted lines

>  (3) when updating from the upstream results in a change in .gitmodules
>      file that changes the previously suggested default the user
>      considered, tell that to the user and have him/her choose.  If you
>      took (a) in the previous step, you can use "git diff" to determine if
>      the suggested default has changed; if you took (b) in the previous
>      step, you can compare submodule.<name>.update in .gitmodules with
>      submodule.<name>.updateSuggested to do so; if you did (c), you are on
>      your own ;-).  After the user updates (or chooses to keep the current
>      setting), record the current suggested default just like you did at
>      the init time in step (2).
> 
> One thing to be careful is in (3) you should not bother users who chose to
> ignore the upstream default (i.e. has submodule.<name>.update set
> differently from what is suggested by the .gitmodules at the time of
> initialization).  The reason (3) updates the "current suggested default"
> is exactly for that purpose---the user has seen what the last suggested
> default was, and decided to either go with it or have his/her own setting.

Consider the following situation: The .git directories of the submodules reside in the .git directory of the superproject so their work trees can be safely deleted and we have means to let upstream configure which submodules should be populated on clone. (Hopefully this is the future ;-)

What happens when we fetch a commit which records a new submodule marked to be populated on clone in the .gitmodules of that commit? I assume we would want to fetch the bare submodule into a subdirectory of the .git directory of the superproject so that we have it present so we can populate it when the superproject's commit is checked out later, no?

Should we ask the user if he wants to fetch the bare submodule into the .git directory of the superproject or to ignore the clone setting while fetching? Should we ask him again on checkout time if he wants to use the upstream setting of checking out the submodule? Or should we just let it happen and when the user decides that he never wanted this submodule he says so in his .git/config while everybody who is happy with the default just moves on? (And of course we would honor any configurations the user did beforehand, like e.g. ignoring all upstream clone defaults)

I have the impression that using submodules won't work smoothly unless we honor the defaults set by upstream until told otherwise by the user. If we copy the settings into .git/config right away we take away much of the flexibility that I believe is needed here, and I can't really see the upsides of that. But the downside is that the setting is copied at an random point in time and therefore is rather arbitrary.

Another example is the repo where submodules normally use the on-demand fetch mode (so everybody only gets those submodule commits he really needs) while having topic branches where certain submodules are always fetched in full to be able to record new commits of those in the superproject. Depending on what branch you were when the copy into .git/config occurred you would be stuck with either setting, which I think is suboptimal.

What am I missing?