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? > Cloning into 'qtbase'... > remote: Counting objects: 267400, done. > remote: Compressing objects: 100% (61070/61070), done. > remote: Total 267400 (delta 210431), reused 258876 (delta 202642) > Receiving objects: 100% (267400/267400), 136.23 MiB | 6.73 MiB/s, done. > Resolving deltas: 100% (210431/210431), done. > Checking connectivity... done. > error: pathspec 'origin/master' did not match any file(s) known to git. > Unable to setup cloned submodule 'qtbase' > > Bisection points to 23d25e48f5ead73c9ce233986f90791abec9f1e8 (W. > Trevor King: submodule: explicit local branch creation in > module_clone). Looking at the patch, it seems to introduce an implicit > assumption on the submodule origin having a "master" branch. Is this > an intended change in behaviour? 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
