Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> Am 07.09.2015 um 01:43 schrieb Eric Sunshine:
>
>> My concern in asking was that some future person might come up with
>> another scenario which also wants to use a "magic value" and would
>> have to invent / arrive at another "illegal" representation. Hence, an
>> explicit setting might be more appropriate. However, as stated, I
>> don't even use submodules, so I may be far off the mark. I've cc'd a
>> few of the submodule maintainers with the hope that they will chime
>> in.
>
> Added Trevor to the CC, who is the original author of --remote (see
> 06b1abb5b).
>
> While I believe that adding such functionality makes perfect sense,
> I do not find it terribly obvious that setting the branch to '@' will
> make --remote skip this submodule. I wouldn't care so much if we'd
> only use this value internally, but this is user visible (and has to
> be set by the user if she wants to skip a submodule in --remote).
>
> Setting the branch to an empty value feels a bit more natural, but
> I'm not so sure our config handling supports that well (we seem to
> assume in quite some places that empty equals unset). So I tend to
> prefer a new option for that.
As I stare at both the code change and log message of 06b1abb5
(submodule update: add --remote for submodule's upstream changes,
2012-12-19), I cannot shake this feeling that the change to default
submodule.$name.branch to 'master' is doubly misdesigned.
The stated goal of users of --remote is to declare "This submodule
does not care what the top-level integrator happened to have seen at
the tip when the integration of the history of submodule. It always
follows the tip of a specific branch at the upstream."
If we were to use any default, the only justification would be "the
users of --remote would want this mode of update to happen for all
submodules, and having to specify which specific branch to be
followed is too cumbersome". But if that is the case, defaulting to
'master' does not make any sense---if it defaulted to 'HEAD' for
each submodule, it may have made some sense, as that is the usual
convention to denote which branch is the default branch in a
repository.
Also Anders' proposal refutes that "when --remote is used, all
submodules should behave that way" assumption.
I wonder if it is a sensible way forward to introduce a new
configuration variable 'submodule.remoteFallBackBranch' so that the
users can customize this line (near l.800 in git-submodule.sh)
branch=$(get_submodule_config "$name" branch master)
The possible values for that new configuration value would be:
- an empty string: disable "update --remote" for any submodule
'$name' for which submodule.$name.branch is not set.
- 'master': behave the same way as the current code; we can make
this the default, when submodule.remoteFallBackBranch is unset,
to ease transition.
- any user-chosen branch name. On notable example may be 'HEAD',
which 06b1abb5 (submodule update: add --remote for submodule's
upstream changes, 2012-12-19) should have chosen as the
default.
But I am not the target audience of "update --remote", so let's hear
what the real-world use cases are.
--
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