On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote: > Am 27.03.2014 18:16, schrieb Junio C Hamano: > > Johan Herland <jo...@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.
> > 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
signature.asc
Description: OpenPGP digital signature
