Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> Am 27.03.2014 16:52, schrieb W. Trevor King:
>> On Thu, Mar 27, 2014 at 03:21:49PM +0100, Johan Herland wrote:
>>> I just found a failure to checkout a project with submodules where
>>> there is no explicit submodule branch configuration, and the
>>> submodules happen to not have a "master" branch:
>>
>> The docs say [1]:
>>
>> A remote branch name for tracking updates in the upstream submodule.
>> If the option is not specified, it defaults to 'master'.
>
> But the "branch" setting isn't configured for Qt, the .gitmodules
> file contains only this:
>
> [submodule "qtbase"]
> path = qtbase
> url = ../qtbase.git
> ...
>
>> which is what we do now. Working around that to default to the
>> upstream submodule's HEAD is possible (you can just use --branch
>> HEAD), but I think it's easier to just explicitly specify your
>> preferred branch.
>
> That is *not* easier, as Johan did not have to do that before.
>
> I think your patch 23d25e48f5ead73c9ce233986f90791abec9f1e8 does
> not do what the commit message promised:
>
> With this change, folks cloning submodules for the first time via:
>
> $ git submodule update ...
>
> will get a local branch instead of a detached HEAD, unless they are
> using the default checkout-mode updates.
>
> And Qt uses the "default checkout-mode updates" and doesn't have
> "branch" configured either. So we are facing a serious regression
> here.
There are two potential issues (and a half) then:
- When cloning with the "default checkout-mode updates", the new
feature to avoid detaching the HEAD should not kick in at all.
- For a repository that does not have that "branch" thing
configured, the doc says that it will default to 'master'.
I do not think this was brought up during the review, but is it a
sensible default if the project does not even have that branch?
What are viable alternatives?
- use 'master' and fail just the way Johan saw?
- use any random branch that happens to be at the same commit as
what is being checked out?
- use the branch "clone" for the submodule repository saw the
upstream was pointing at with its HEAD?
- something else?
- Johan's set-up was apparently not covered in the addition to t/
in 23d25e48 (submodule: explicit local branch creation in
module_clone, 2014-01-26)---otherwise we would have caught this
regression. Are there other conditions that are not covered?
--
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