All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: "W. Trevor King" <wking@tremily.us>,
	Johan Herland <johan@herland.net>,
	Git mailing list <git@vger.kernel.org>,
	Heiko Voigt <hvoigt@hvoigt.net>
Subject: Re: Possible regression in master? (submodules without a "master" branch)
Date: Thu, 27 Mar 2014 11:30:51 -0700	[thread overview]
Message-ID: <xmqq8urvebok.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <53345E85.7070205@web.de> (Jens Lehmann's message of "Thu, 27 Mar 2014 18:23:17 +0100")

Jens Lehmann <Jens.Lehmann@web.de> 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?

  reply	other threads:[~2014-03-27 18:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 14:21 Possible regression in master? (submodules without a "master" branch) Johan Herland
2014-03-27 15:52 ` W. Trevor King
2014-03-27 15:57   ` W. Trevor King
2014-03-27 17:23   ` Jens Lehmann
2014-03-27 18:30     ` Junio C Hamano [this message]
2014-03-27 22:55       ` Jens Lehmann
2014-03-27 23:27         ` Johan Herland
2014-03-28  2:33         ` W. Trevor King
2014-03-27 17:16 ` Junio C Hamano
2014-03-27 17:31   ` Jens Lehmann
2014-03-27 18:54     ` W. Trevor King
2014-03-27 19:39       ` Junio C Hamano
2014-03-27 20:27         ` Heiko Voigt
2014-03-27 23:06           ` Jens Lehmann
2014-03-27 23:21           ` Johan Herland
2014-03-28  3:05             ` W. Trevor King
2014-03-28  3:36               ` [RFC] submodule: change submodule.<name>.branch default from master to HEAD W. Trevor King
2014-03-28  3:43                 ` Eric Sunshine
2014-03-28  3:52                   ` W. Trevor King
2014-03-28  3:58                     ` W. Trevor King
2014-03-28 16:57                       ` Jens Lehmann
2014-03-28 17:10                         ` W. Trevor King
2014-03-31 19:31                           ` Jens Lehmann
2014-03-28 17:28                         ` Junio C Hamano
2014-03-31 19:35                 ` Jens Lehmann
2014-03-31 20:38                   ` W. Trevor King
2014-03-31 20:45                   ` Junio C Hamano
2014-03-27 21:01         ` submodule.<path>.branch vs. submodule.<name>.branch (was: Possible regression in master? (submodules without a "master" branch) W. Trevor King
2014-03-27 21:37           ` submodule.<path>.branch vs. submodule.<name>.branch Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq8urvebok.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    --cc=johan@herland.net \
    --cc=wking@tremily.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.