Re: Re: Possible regression in master? (submodules without a "master" branch)

From: W. Trevor King <wking@tremily.us>
Date: Mar 27, 2014, 18:54 UTC
Message-ID: <20140327185405.GS4008@odin.tremily.us>
In-Reply-To: <5334606F.5010109@web.de>

On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:

Show 20 quoted lines

> Am 27.03.2014 18:16, schrieb Junio C Hamano:
> > Johan Herland <johan@herland.net> writes:
> > 
> >> 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:
> >>
> >>   git clone git://gitorious.org/qt/qt5.git qt5
> >>   cd qt5
> >>   git submodule init qtbase
> >>   git submodule update
> >>
> >> In current master, the last command fails with the following output:
> > 
> > ... and with a bug-free system, what does it do instead?  Just clone
> > 'qtbase' and make a detached-head checkout at the commit recorded in
> > the superproject's tree, or something else?
> 
> After reverting 23d25e48f5ead73 on current master it clones 'qtbase'
> nicely with a detached HEAD.

Fixing this for initial update clone is pretty easy, we just need to unset start_point before calling module_clone if submodule.<name>.branch is not set. However, that's just going to push remote branch ambiguity problems back to the --remote update functionality. What should happen when submodule.<name>.branch is not set and you run a --remote update, which has used:

    git rev-parse "${remote_name}/${branch}"

since the submodule.<name>.branch setting was introduced in 06b1abb (submodule update: add --remote for submodule's upstream changes, 2012-12-19)?

gitmodules(5) is pretty clear that 'submodule.<name>.branch' defaults to master (and not upstream's HEAD), do we want to adjust this at the same time? For folks using non-checkout updates, should the preferred local branch name still be master, or should it match upstream's HEAD? If upstream's HEAD changes, should we update the local branch name to stay in sync? If we don't rename the local branch, do we keep integrating remote changes from upstream's original branch or keep integrating HEAD?

I think this would all be simpler if we just made the superproject-branch-to-submodule-local-branch binding explicit and pushed this submodule-to-upstream-subproject binding down into the submodule itself [1]. Then the usual single-project commands would handle the tricky remote-tracking cases (with explicit branch.<name>.merge entries, etc.), and a dumb syncing mechanism would pull those clever choices back up into the superproject for distribution.

Show 5 quoted lines

> > If an existing set-up that was working in a sensible way is broken
> > by a change that assumes something that should not be assumed,
> > then that is a serious regression, I would have to say.
> 
> Yes, especially as it promised to not change this use case.

Sorry. A side effect of relying too much on our existing documentation and not enough on testing actual use cases. I can work up some non-master submodule tests to go with the fix.

Cheers, Trevor

[1]: http://thread.gmane.org/gmane.comp.version-control.git/239955/focus=240336

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy