{"thread":{"id":"36302","subject":"Possible regression in master? (submodules without a \"master\" branch)","startedAt":"2014-03-27T14:21:49Z","lastAt":"2014-03-31T20:45:24Z","messageCount":29,"participants":["Johan Herland","W. Trevor King","Junio C Hamano","Jens Lehmann","Heiko Voigt","Eric Sunshine"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"237903","messageId":"CALKQrgeRJRoyC-UV7J98U1qQfqEFr_H1sEfAWd0GbstZagUisw@mail.gmail.com","threadId":"36302","inReplyTo":null,"subject":"Possible regression in master? (submodules without a \"master\" branch)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-03-27T14:21:49Z","receivedAt":"2014-03-27T14:21:49Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"Hi,\n\nI just found a failure to checkout a project with submodules where\nthere is no explicit submodule branch configuration, and the\nsubmodules happen to not have a \"master\" branch:\n\n git clone git://gitorious.org/qt/qt5.git qt5\n cd qt5\n git submodule init qtbase\n git submodule update\n\nIn current master, the last command fails with the following output:\n\n Cloning into 'qtbase'...\n remote: Counting objects: 267400, done.\n remote: Compressing objects: 100% (61070/61070), done.\n remote: Total 267400 (delta 210431), reused 258876 (delta 202642)\n Receiving objects: 100% (267400/267400), 136.23 MiB | 6.73 MiB/s, done.\n Resolving deltas: 100% (210431/210431), done.\n Checking connectivity... done.\n error: pathspec 'origin/master' did not match any file(s) known to git.\n Unable to setup cloned submodule 'qtbase'\n\nBisection points to 23d25e48f5ead73c9ce233986f90791abec9f1e8 (W.\nTrevor King: submodule: explicit local branch creation in\nmodule_clone). Looking at the patch, it seems to introduce an implicit\nassumption on the submodule origin having a \"master\" branch. Is this\nan intended change in behaviour?\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"237907","messageId":"20140327155208.GM4008@odin.tremily.us","threadId":"36302","inReplyTo":"CALKQrgeRJRoyC-UV7J98U1qQfqEFr_H1sEfAWd0GbstZagUisw@mail.gmail.com","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-27T15:52:08Z","receivedAt":"2014-03-27T15:52:08Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Mar 27, 2014 at 03:21:49PM +0100, Johan Herland wrote:\n> I just found a failure to checkout a project with submodules where\n> there is no explicit submodule branch configuration, and the\n> submodules happen to not have a \"master\" branch:\n\nThe docs say [1]:\n\n A remote branch name for tracking updates in the upstream submodule.\n If the option is not specified, it defaults to 'master'.\n\nwhich is what we do now. Working around that to default to the\nupstream submodule's HEAD is possible (you can just use --branch\nHEAD), but I think it's easier to just explicitly specify your\npreferred branch.\n\nCheers,\nTrevor\n\n[1]: submodule..branch in gitmodules(5)\n http://git-scm.com/docs/gitmodules.html\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237908","messageId":"20140327155748.GN4008@odin.tremily.us","threadId":"36302","inReplyTo":"20140327155208.GM4008@odin.tremily.us","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-27T15:57:48Z","receivedAt":"2014-03-27T15:57:48Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Mar 27, 2014 at 08:52:08AM -0700, W. Trevor King wrote:\n> Working around that to default to the upstream submodule's HEAD is\n> possible (you can just use --branch HEAD)\n\nActually, this is probably not a good idea. The initial submodule\naddition works:\n\n $ git submodule add -b HEAD /tmp/submod.git submod\n Cloning into 'submod'...\n done.\n\nBut subsequent log calls (from the superproject) do not:\n\n $ git log\n fatal: bad default revision 'HEAD'\n $ echo $?\n 128\n\nand status calls (from the superproject) also have trouble:\n\n $ git status\n warning: refname 'HEAD' is ambiguous\n warning: refname 'HEAD' is ambiguous.\n On branch master\n …\n\nSo it's better to just specify your preferred upstream branch directly\n(e.g. --branch next).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237915","messageId":"xmqqob0ref3v.fsf@gitster.dls.corp.google.com","threadId":"36302","inReplyTo":"CALKQrgeRJRoyC-UV7J98U1qQfqEFr_H1sEfAWd0GbstZagUisw@mail.gmail.com","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-27T17:16:52Z","receivedAt":"2014-03-27T17:16:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> I just found a failure to checkout a project with submodules where\n> there is no explicit submodule branch configuration, and the\n> submodules happen to not have a \"master\" branch:\n>\n> git clone git://gitorious.org/qt/qt5.git qt5\n> cd qt5\n> git submodule init qtbase\n> git submodule update\n>\n> In current master, the last command fails with the following output:\n\n... and with a bug-free system, what does it do instead? Just clone\n'qtbase' and make a detached-head checkout at the commit recorded in\nthe superproject's tree, or something else?\n\n> Cloning into 'qtbase'...\n> remote: Counting objects: 267400, done.\n> remote: Compressing objects: 100% (61070/61070), done.\n> remote: Total 267400 (delta 210431), reused 258876 (delta 202642)\n> Receiving objects: 100% (267400/267400), 136.23 MiB | 6.73 MiB/s, done.\n> Resolving deltas: 100% (210431/210431), done.\n> Checking connectivity... done.\n> error: pathspec 'origin/master' did not match any file(s) known to git.\n> Unable to setup cloned submodule 'qtbase'\n>\n> Bisection points to 23d25e48f5ead73c9ce233986f90791abec9f1e8 (W.\n> Trevor King: submodule: explicit local branch creation in\n> module_clone). Looking at the patch, it seems to introduce an implicit\n> assumption on the submodule origin having a \"master\" branch. Is this\n> an intended change in behaviour?\n\nIf an existing set-up that was working in a sensible way is broken\nby a change that assumes something that should not be assumed, then\nthat is a serious regression, I would have to say.\n"},{"id":"237916","messageId":"53345E85.7070205@web.de","threadId":"36302","inReplyTo":"20140327155208.GM4008@odin.tremily.us","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-27T17:23:17Z","receivedAt":"2014-03-27T17:23:17Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.03.2014 16:52, schrieb W. Trevor King:\n> On Thu, Mar 27, 2014 at 03:21:49PM +0100, Johan Herland wrote:\n>> I just found a failure to checkout a project with submodules where\n>> there is no explicit submodule branch configuration, and the\n>> submodules happen to not have a \"master\" branch:\n> \n> The docs say [1]:\n> \n> A remote branch name for tracking updates in the upstream submodule.\n> If the option is not specified, it defaults to 'master'.\n\nBut the \"branch\" setting isn't configured for Qt, the .gitmodules\nfile contains only this:\n\n[submodule \"qtbase\"]\n\tpath = qtbase\n\turl = ../qtbase.git\n...\n\n> which is what we do now. Working around that to default to the\n> upstream submodule's HEAD is possible (you can just use --branch\n> HEAD), but I think it's easier to just explicitly specify your\n> preferred branch.\n\nThat is *not* easier, as Johan did not have to do that before.\n\nI think your patch 23d25e48f5ead73c9ce233986f90791abec9f1e8 does\nnot do what the commit message promised:\n\n With this change, folks cloning submodules for the first time via:\n\n $ git submodule update ...\n\n will get a local branch instead of a detached HEAD, unless they are\n using the default checkout-mode updates.\n\nAnd Qt uses the \"default checkout-mode updates\" and doesn't have\n\"branch\" configured either. So we are facing a serious regression\nhere.\n\n> Cheers,\n> Trevor\n> \n> [1]: submodule..branch in gitmodules(5)\n> http://git-scm.com/docs/gitmodules.html\n> \n"},{"id":"237917","messageId":"5334606F.5010109@web.de","threadId":"36302","inReplyTo":"xmqqob0ref3v.fsf@gitster.dls.corp.google.com","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-27T17:31:27Z","receivedAt":"2014-03-27T17:31:27Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.03.2014 18:16, schrieb Junio C Hamano:\n> Johan Herland writes:\n> \n>> I just found a failure to checkout a project with submodules where\n>> there is no explicit submodule branch configuration, and the\n>> submodules happen to not have a \"master\" branch:\n>>\n>> git clone git://gitorious.org/qt/qt5.git qt5\n>> cd qt5\n>> git submodule init qtbase\n>> git submodule update\n>>\n>> In current master, the last command fails with the following output:\n> \n> ... and with a bug-free system, what does it do instead? Just clone\n> 'qtbase' and make a detached-head checkout at the commit recorded in\n> the superproject's tree, or something else?\n\nAfter reverting 23d25e48f5ead73 on current master it clones 'qtbase'\nnicely with a detached HEAD.\n\n>> Cloning into 'qtbase'...\n>> remote: Counting objects: 267400, done.\n>> remote: Compressing objects: 100% (61070/61070), done.\n>> remote: Total 267400 (delta 210431), reused 258876 (delta 202642)\n>> Receiving objects: 100% (267400/267400), 136.23 MiB | 6.73 MiB/s, done.\n>> Resolving deltas: 100% (210431/210431), done.\n>> Checking connectivity... done.\n>> error: pathspec 'origin/master' did not match any file(s) known to git.\n>> Unable to setup cloned submodule 'qtbase'\n>>\n>> Bisection points to 23d25e48f5ead73c9ce233986f90791abec9f1e8 (W.\n>> Trevor King: submodule: explicit local branch creation in\n>> module_clone). Looking at the patch, it seems to introduce an implicit\n>> assumption on the submodule origin having a \"master\" branch. Is this\n>> an intended change in behaviour?\n> \n> If an existing set-up that was working in a sensible way is broken\n> by a change that assumes something that should not be assumed, then\n> that is a serious regression, I would have to say.\n\nYes, especially as it promised to not change this use case.\n"},{"id":"237923","messageId":"xmqq8urvebok.fsf@gitster.dls.corp.google.com","threadId":"36302","inReplyTo":"53345E85.7070205@web.de","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-27T18:30:51Z","receivedAt":"2014-03-27T18:30:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Am 27.03.2014 16:52, schrieb W. Trevor King:\n>> On Thu, Mar 27, 2014 at 03:21:49PM +0100, Johan Herland wrote:\n>>> I just found a failure to checkout a project with submodules where\n>>> there is no explicit submodule branch configuration, and the\n>>> submodules happen to not have a \"master\" branch:\n>> \n>> The docs say [1]:\n>> \n>> A remote branch name for tracking updates in the upstream submodule.\n>> If the option is not specified, it defaults to 'master'.\n>\n> But the \"branch\" setting isn't configured for Qt, the .gitmodules\n> file contains only this:\n>\n> [submodule \"qtbase\"]\n> \tpath = qtbase\n> \turl = ../qtbase.git\n> ...\n>\n>> which is what we do now. Working around that to default to the\n>> upstream submodule's HEAD is possible (you can just use --branch\n>> HEAD), but I think it's easier to just explicitly specify your\n>> preferred branch.\n>\n> That is *not* easier, as Johan did not have to do that before.\n>\n> I think your patch 23d25e48f5ead73c9ce233986f90791abec9f1e8 does\n> not do what the commit message promised:\n>\n> With this change, folks cloning submodules for the first time via:\n>\n> $ git submodule update ...\n>\n> will get a local branch instead of a detached HEAD, unless they are\n> using the default checkout-mode updates.\n>\n> And Qt uses the \"default checkout-mode updates\" and doesn't have\n> \"branch\" configured either. So we are facing a serious regression\n> here.\n\nThere are two potential issues (and a half) then:\n\n - When cloning with the \"default checkout-mode updates\", the new\n feature to avoid detaching the HEAD should not kick in at all.\n\n - For a repository that does not have that \"branch\" thing\n configured, the doc says that it will default to 'master'.\n\n I do not think this was brought up during the review, but is it a\n sensible default if the project does not even have that branch?\n\n What are viable alternatives?\n\n - use 'master' and fail just the way Johan saw?\n\n - use any random branch that happens to be at the same commit as\n what is being checked out?\n\n - use the branch \"clone\" for the submodule repository saw the\n upstream was pointing at with its HEAD?\n\n - something else?\n\n - Johan's set-up was apparently not covered in the addition to t/\n in 23d25e48 (submodule: explicit local branch creation in\n module_clone, 2014-01-26)---otherwise we would have caught this\n regression. Are there other conditions that are not covered?\n"},{"id":"237939","messageId":"20140327185405.GS4008@odin.tremily.us","threadId":"36302","inReplyTo":"5334606F.5010109@web.de","subject":"Re: Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-27T18:54:05Z","receivedAt":"2014-03-27T18:54:05Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:\n> Am 27.03.2014 18:16, schrieb Junio C Hamano:\n> > Johan Herland writes:\n> > \n> >> I just found a failure to checkout a project with submodules where\n> >> there is no explicit submodule branch configuration, and the\n> >> submodules happen to not have a \"master\" branch:\n> >>\n> >> git clone git://gitorious.org/qt/qt5.git qt5\n> >> cd qt5\n> >> git submodule init qtbase\n> >> git submodule update\n> >>\n> >> In current master, the last command fails with the following output:\n> > \n> > ... and with a bug-free system, what does it do instead? Just clone\n> > 'qtbase' and make a detached-head checkout at the commit recorded in\n> > the superproject's tree, or something else?\n> \n> After reverting 23d25e48f5ead73 on current master it clones 'qtbase'\n> nicely with a detached HEAD.\n\nFixing this for initial update clone is pretty easy, we just need to\nunset start_point before calling module_clone if\nsubmodule..branch is not set. However, that's just going to\npush remote branch ambiguity problems back to the --remote update\nfunctionality. What should happen when submodule..branch is not\nset and you run a --remote update, which has used:\n\n git rev-parse \"${remote_name}/${branch}\"\n\nsince the submodule..branch setting was introduced in 06b1abb\n(submodule update: add --remote for submodule's upstream changes,\n2012-12-19)?\n\ngitmodules(5) is pretty clear that 'submodule..branch' defaults\nto master (and not upstream's HEAD), do we want to adjust this at the\nsame time? For folks using non-checkout updates, should the preferred\nlocal branch name still be master, or should it match upstream's HEAD?\nIf upstream's HEAD changes, should we update the local branch name to\nstay in sync? If we don't rename the local branch, do we keep\nintegrating remote changes from upstream's original branch or keep\nintegrating HEAD?\n\nI think this would all be simpler if we just made the\nsuperproject-branch-to-submodule-local-branch binding explicit and\npushed this submodule-to-upstream-subproject binding down into the\nsubmodule itself [1]. Then the usual single-project commands would\nhandle the tricky remote-tracking cases (with explicit\nbranch..merge entries, etc.), and a dumb syncing mechanism would\npull those clever choices back up into the superproject for\ndistribution.\n\n> > If an existing set-up that was working in a sensible way is broken\n> > by a change that assumes something that should not be assumed,\n> > then that is a serious regression, I would have to say.\n> \n> Yes, especially as it promised to not change this use case.\n\nSorry. A side effect of relying too much on our existing\ndocumentation and not enough on testing actual use cases. I can work\nup some non-master submodule tests to go with the fix.\n\nCheers,\nTrevor\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/239955/focus=240336\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237941","messageId":"xmqqwqffctyg.fsf@gitster.dls.corp.google.com","threadId":"36302","inReplyTo":"20140327185405.GS4008@odin.tremily.us","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-27T19:39:03Z","receivedAt":"2014-03-27T19:39:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:\n>> Am 27.03.2014 18:16, schrieb Junio C Hamano:\n>> > Johan Herland writes:\n>> > \n>> >> I just found a failure to checkout a project with submodules where\n>> >> there is no explicit submodule branch configuration, and the\n>> >> submodules happen to not have a \"master\" branch:\n>> >>\n>> >> git clone git://gitorious.org/qt/qt5.git qt5\n>> >> cd qt5\n>> >> git submodule init qtbase\n>> >> git submodule update\n>> >>\n>> >> In current master, the last command fails with the following output:\n>> > \n>> > ... and with a bug-free system, what does it do instead? Just clone\n>> > 'qtbase' and make a detached-head checkout at the commit recorded in\n>> > the superproject's tree, or something else?\n>> \n>> After reverting 23d25e48f5ead73 on current master it clones 'qtbase'\n>> nicely with a detached HEAD.\n>\n> Fixing this for initial update clone is pretty easy, we just need to\n> unset start_point before calling module_clone if\n> submodule..branch is not set. \n\nThere is this bit for \"update\" in git-submodule.txt:\n\n For updates that clone missing submodules, checkout-mode updates\n will create submodules with detached HEADs; all other modes will\n create submodules with a local branch named after\n submodule..branch.\n\n [side note] Isn't that a typo of submodule..branch?\n\nSo the proposed change is to make the part before semicolon true?\nIf we are not newly cloning (because we already have it), if the\nsubmodule..branch is not set *OR* refers to a branch that does\nnot even exist, shouldn't we either (1) abort as an error, or (2) do\nthe same and detach?\n\n> However, that's just going to\n> push remote branch ambiguity problems back to the --remote update\n> functionality. What should happen when submodule..branch is not\n> set and you run a --remote update, which has used:\n>\n> git rev-parse \"${remote_name}/${branch}\"\n>\n> since the submodule..branch setting was introduced in 06b1abb\n> (submodule update: add --remote for submodule's upstream changes,\n> 2012-12-19)?\n\nIsn't --remote about following one specific branch the user who\nissues that command has in mind? If you as the end user did not\ngive any indication which branch you meant, e.g. by leaving the\nsubmodule..branch empty, shouldn't that be diagnosed as an\nerror?\n\n> gitmodules(5) is pretty clear that 'submodule..branch' defaults\n> to master (and not upstream's HEAD), do we want to adjust this at the\n> same time?\n\nThat may be likely. If the value set to a configuration variable\ncauses an established behaviour of a program change a lot, silently\ndefaulting that variable to something many people are expected to\nhave (e.g. 'master') would likely to cause a usability regression.\n\n>> > If an existing set-up that was working in a sensible way is broken\n>> > by a change that assumes something that should not be assumed,\n>> > then that is a serious regression, I would have to say.\n>> \n>> Yes, especially as it promised to not change this use case.\n>\n> Sorry. A side effect of relying too much on our existing\n> documentation and not enough on testing actual use cases. I can work\n> up some non-master submodule tests to go with the fix.\n\nI was wondering if we need to revert the merge with that\nbranch out of 'master', or submodule folks can work on a set of\nfixes to apply on top.\n\nWill wait to see how it goes. Thanks.\n"},{"id":"237944","messageId":"20140327202702.GA3984@sandbox-ub","threadId":"36302","inReplyTo":"xmqqwqffctyg.fsf@gitster.dls.corp.google.com","subject":"Re: Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2014-03-27T20:27:02Z","receivedAt":"2014-03-27T20:27:02Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:\n> >> Am 27.03.2014 18:16, schrieb Junio C Hamano:\n> >> > Johan Herland writes:\n> >> > \n> >> >> I just found a failure to checkout a project with submodules where\n> >> >> there is no explicit submodule branch configuration, and the\n> >> >> submodules happen to not have a \"master\" branch:\n> >> >>\n> >> >> git clone git://gitorious.org/qt/qt5.git qt5\n> >> >> cd qt5\n> >> >> git submodule init qtbase\n> >> >> git submodule update\n> >> >>\n> >> >> In current master, the last command fails with the following output:\n> >> > \n> >> > ... and with a bug-free system, what does it do instead? Just clone\n> >> > 'qtbase' and make a detached-head checkout at the commit recorded in\n> >> > the superproject's tree, or something else?\n> >> \n> >> After reverting 23d25e48f5ead73 on current master it clones 'qtbase'\n> >> nicely with a detached HEAD.\n> >\n> > Fixing this for initial update clone is pretty easy, we just need to\n> > unset start_point before calling module_clone if\n> > submodule..branch is not set. \n> \n> There is this bit for \"update\" in git-submodule.txt:\n> \n> For updates that clone missing submodules, checkout-mode updates\n> will create submodules with detached HEADs; all other modes will\n> create submodules with a local branch named after\n> submodule..branch.\n> \n> [side note] Isn't that a typo of submodule..branch?\n\nYep, thats is a typo. Trevor will you fix that as well? Or how should be\ndo that? Since its just such a small change.\n\n> So the proposed change is to make the part before semicolon true?\n> If we are not newly cloning (because we already have it), if the\n> submodule..branch is not set *OR* refers to a branch that does\n> not even exist, shouldn't we either (1) abort as an error, or (2) do\n> the same and detach?\n\nI would expect \"(1) abort as an error\" since the user is not getting what\nhe would expect.\n\n> > However, that's just going to\n> > push remote branch ambiguity problems back to the --remote update\n> > functionality. What should happen when submodule..branch is not\n> > set and you run a --remote update, which has used:\n> >\n> > git rev-parse \"${remote_name}/${branch}\"\n> >\n> > since the submodule..branch setting was introduced in 06b1abb\n> > (submodule update: add --remote for submodule's upstream changes,\n> > 2012-12-19)?\n> \n> Isn't --remote about following one specific branch the user who\n> issues that command has in mind? If you as the end user did not\n> give any indication which branch you meant, e.g. by leaving the\n> submodule..branch empty, shouldn't that be diagnosed as an\n> error?\n\nWell to simplify things there was this fallback to origin/master\n(similar to the master branch we create on init) since that is a branch\nwhich many projects have. E.g. for the users that share one central\nserver and just directly commit, push and pull to/from master. They\nwould have an easy way to start working in a submodule, by simply saying\n--remote and then committing to master. At least that is what I\nimagine.\n\n> > gitmodules(5) is pretty clear that 'submodule..branch' defaults\n> > to master (and not upstream's HEAD), do we want to adjust this at the\n> > same time?\n> \n> That may be likely. If the value set to a configuration variable\n> causes an established behaviour of a program change a lot, silently\n> defaulting that variable to something many people are expected to\n> have (e.g. 'master') would likely to cause a usability regression.\n\nIMO this branch configuration should completely ignored in the default,\nnon --remote, usage. Since we simply checkout a specific SHA1 in this\ncase, that should be possible.\n\nCheers Heiko\n"},{"id":"237945","messageId":"20140327210106.GV4008@odin.tremily.us","threadId":"36302","inReplyTo":"xmqqwqffctyg.fsf@gitster.dls.corp.google.com","subject":"submodule..branch vs. submodule..branch (was: Possible regression in master? (submodules without a \"master\" branch).","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-27T21:01:07Z","receivedAt":"2014-03-27T21:01:07Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"I'm breaking this off into a sub-thread, so it doesn't distract from\nthe main issue.\n\nOn Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:\n> There is this bit for \"update\" in git-submodule.txt:\n> \n> For updates that clone missing submodules, checkout-mode updates\n> will create submodules with detached HEADs; all other modes will\n> create submodules with a local branch named after\n> submodule..branch.\n> \n> [side note] Isn't that a typo of submodule..branch?\n\nGood catch.\n\nThe transition from submodule..* to submodule..* happened\nin 73b0898d (Teach \"git submodule add\" the --name option, 2012-09-30),\nwhich landed in v1.8.1-rc0 on 2012-12-03. The first\nsubmodule..branch reference landed a short time later in\nb9289227 (submodule add: If --branch is given, record it in\n.gitmodules, 2012-12-19), and I was probably just not aware of\n73b0898d. The second submodule..branch reference landed in\n23d25e48 (submodule: explicit local branch creation in module_clone,\n2014-01-26), and is just a copy paste error. Both should be updated\nto submodule..branch.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237947","messageId":"xmqqsiq3coga.fsf@gitster.dls.corp.google.com","threadId":"36302","inReplyTo":"20140327210106.GV4008@odin.tremily.us","subject":"Re: submodule..branch vs. submodule..branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-27T21:37:57Z","receivedAt":"2014-03-27T21:37:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n>> [side note] Isn't that a typo of submodule..branch?\n>\n> Good catch.\n>\n> The transition from submodule..* to submodule..* happened\n> in 73b0898d (Teach \"git submodule add\" the --name option, 2012-09-30),\n> which landed in v1.8.1-rc0 on 2012-12-03. \n\nThanks for digging.\n\nStrictly speaking, I think this was not even a transition (rather,\nthere was no way to give a submodule a name that is different from\nits path). In any version of git whose git-submodule.sh has\nmodule_name helper function, the path and the name were conceptually\ntwo different things, and we should have been using the name, not\npath, throughout.\n\n> ... Both should be updated\n> to submodule..branch.\n\nI agree. Thanks.\n"},{"id":"237952","messageId":"5334AC59.7010605@web.de","threadId":"36302","inReplyTo":"xmqq8urvebok.fsf@gitster.dls.corp.google.com","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-27T22:55:21Z","receivedAt":"2014-03-27T22:55:21Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.03.2014 19:30, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> Am 27.03.2014 16:52, schrieb W. Trevor King:\n>>> On Thu, Mar 27, 2014 at 03:21:49PM +0100, Johan Herland wrote:\n>>>> I just found a failure to checkout a project with submodules where\n>>>> there is no explicit submodule branch configuration, and the\n>>>> submodules happen to not have a \"master\" branch:\n>>>\n>>> The docs say [1]:\n>>>\n>>> A remote branch name for tracking updates in the upstream submodule.\n>>> If the option is not specified, it defaults to 'master'.\n>>\n>> But the \"branch\" setting isn't configured for Qt, the .gitmodules\n>> file contains only this:\n>>\n>> [submodule \"qtbase\"]\n>> \tpath = qtbase\n>> \turl = ../qtbase.git\n>> ...\n>>\n>>> which is what we do now. Working around that to default to the\n>>> upstream submodule's HEAD is possible (you can just use --branch\n>>> HEAD), but I think it's easier to just explicitly specify your\n>>> preferred branch.\n>>\n>> That is *not* easier, as Johan did not have to do that before.\n>>\n>> I think your patch 23d25e48f5ead73c9ce233986f90791abec9f1e8 does\n>> not do what the commit message promised:\n>>\n>> With this change, folks cloning submodules for the first time via:\n>>\n>> $ git submodule update ...\n>>\n>> will get a local branch instead of a detached HEAD, unless they are\n>> using the default checkout-mode updates.\n>>\n>> And Qt uses the \"default checkout-mode updates\" and doesn't have\n>> \"branch\" configured either. So we are facing a serious regression\n>> here.\n> \n> There are two potential issues (and a half) then:\n> \n> - When cloning with the \"default checkout-mode updates\", the new\n> feature to avoid detaching the HEAD should not kick in at all.\n\nYep.\n\n> - For a repository that does not have that \"branch\" thing\n> configured, the doc says that it will default to 'master'.\n> \n> I do not think this was brought up during the review, but is it a\n> sensible default if the project does not even have that branch?\n> \n> What are viable alternatives?\n> \n> - use 'master' and fail just the way Johan saw?\n> \n> - use any random branch that happens to be at the same commit as\n> what is being checked out?\n> \n> - use the branch \"clone\" for the submodule repository saw the\n> upstream was pointing at with its HEAD?\n> \n> - something else?\n\nGood question. Me thinks that when a superproject doesn't have\n'branch' configured and does set 'update' to something other than\n'checkout' for a submodule it should better make sure 'master'\nis a valid branch in there. Everything else sounds like a\nmisconfiguration on the superproject's part that warrants an\nerror. But I may be wrong here as I only use 'checkout' together\nwith a detached HEADs myself. Comments welcome.\n\n> - Johan's set-up was apparently not covered in the addition to t/\n> in 23d25e48 (submodule: explicit local branch creation in\n> module_clone, 2014-01-26)---otherwise we would have caught this\n> regression. Are there other conditions that are not covered?\n\nI suspect so. This is one of the reasons I started the submodule\ntesting framework I posted an RFC for a few days ago, as an attempt\nto start a systematic approach to submodule testing. This is not\nthe first time a breakage was not caught by the tests, so we need\nto do better here. (Note to self: test for the detached HEAD for\nthe checkout case in the framework too)\n"},{"id":"237954","messageId":"5334AEDA.70002@web.de","threadId":"36302","inReplyTo":"20140327202702.GA3984@sandbox-ub","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-27T23:06:02Z","receivedAt":"2014-03-27T23:06:02Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.03.2014 21:27, schrieb Heiko Voigt:\n> On Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:\n>> \"W. Trevor King\" writes:\n>>\n>>> On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:\n>>>> Am 27.03.2014 18:16, schrieb Junio C Hamano:\n>>>>> Johan Herland writes:\n>>>>>\n>>>>>> I just found a failure to checkout a project with submodules where\n>>>>>> there is no explicit submodule branch configuration, and the\n>>>>>> submodules happen to not have a \"master\" branch:\n>>>>>>\n>>>>>> git clone git://gitorious.org/qt/qt5.git qt5\n>>>>>> cd qt5\n>>>>>> git submodule init qtbase\n>>>>>> git submodule update\n>>>>>>\n>>>>>> In current master, the last command fails with the following output:\n>>>>>\n>>>>> ... and with a bug-free system, what does it do instead? Just clone\n>>>>> 'qtbase' and make a detached-head checkout at the commit recorded in\n>>>>> the superproject's tree, or something else?\n>>>>\n>>>> After reverting 23d25e48f5ead73 on current master it clones 'qtbase'\n>>>> nicely with a detached HEAD.\n>>>\n>>> Fixing this for initial update clone is pretty easy, we just need to\n>>> unset start_point before calling module_clone if\n>>> submodule..branch is not set. \n>>\n>> There is this bit for \"update\" in git-submodule.txt:\n>>\n>> For updates that clone missing submodules, checkout-mode updates\n>> will create submodules with detached HEADs; all other modes will\n>> create submodules with a local branch named after\n>> submodule..branch.\n>>\n>> [side note] Isn't that a typo of submodule..branch?\n> \n> Yep, thats is a typo. Trevor will you fix that as well? Or how should be\n> do that? Since its just such a small change.\n> \n>> So the proposed change is to make the part before semicolon true?\n\nDefinitely. But not only for the initial clone, that should hold\ntrue for all subsequent updates too.\n\n>> If we are not newly cloning (because we already have it), if the\n>> submodule..branch is not set *OR* refers to a branch that does\n>> not even exist, shouldn't we either (1) abort as an error, or (2) do\n>> the same and detach?\n> \n> I would expect \"(1) abort as an error\" since the user is not getting what\n> he would expect.\n\nI believe that depends on the 'update' setting. If it is either not\nset or set to 'checkout', it should simply detach when 'branch' is\nnot set. So it is \"(2) do the same and detach\" in that case. Otherwise\nI agree with Heiko.\n\n>>> However, that's just going to\n>>> push remote branch ambiguity problems back to the --remote update\n>>> functionality. What should happen when submodule..branch is not\n>>> set and you run a --remote update, which has used:\n>>>\n>>> git rev-parse \"${remote_name}/${branch}\"\n>>>\n>>> since the submodule..branch setting was introduced in 06b1abb\n>>> (submodule update: add --remote for submodule's upstream changes,\n>>> 2012-12-19)?\n>>\n>> Isn't --remote about following one specific branch the user who\n>> issues that command has in mind? If you as the end user did not\n>> give any indication which branch you meant, e.g. by leaving the\n>> submodule..branch empty, shouldn't that be diagnosed as an\n>> error?\n> \n> Well to simplify things there was this fallback to origin/master\n> (similar to the master branch we create on init) since that is a branch\n> which many projects have. E.g. for the users that share one central\n> server and just directly commit, push and pull to/from master. They\n> would have an easy way to start working in a submodule, by simply saying\n> --remote and then committing to master. At least that is what I\n> imagine.\n\nI'd really like to see more feedback on this from people who actually\nuse the 'merge' and 'rebase' update modes with or without 'branch' set.\n\n>>> gitmodules(5) is pretty clear that 'submodule..branch' defaults\n>>> to master (and not upstream's HEAD), do we want to adjust this at the\n>>> same time?\n>>\n>> That may be likely. If the value set to a configuration variable\n>> causes an established behaviour of a program change a lot, silently\n>> defaulting that variable to something many people are expected to\n>> have (e.g. 'master') would likely to cause a usability regression.\n> \n> IMO this branch configuration should completely ignored in the default,\n> non --remote, usage. Since we simply checkout a specific SHA1 in this\n> case, that should be possible.\n\nYes.\n"},{"id":"237958","messageId":"CALKQrgdAhe0AKk51=__fDWX9QqFH=WVCO=gU+mtO6sb250==0A@mail.gmail.com","threadId":"36302","inReplyTo":"20140327202702.GA3984@sandbox-ub","subject":"Re: Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-03-27T23:21:23Z","receivedAt":"2014-03-27T23:21:23Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"(Thanks to all of you for picking this up and more or less resolving\nit while I was away from email for a few hours...)\n\nOn Thu, Mar 27, 2014 at 9:27 PM, Heiko Voigt wrote:\n> On Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:\n>> \"W. Trevor King\" writes:\n>> > On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:\n>> >> Am 27.03.2014 18:16, schrieb Junio C Hamano:\n>> >> > Johan Herland writes:\n>> >> >> I just found a failure to checkout a project with submodules where\n>> >> >> there is no explicit submodule branch configuration, and the\n>> >> >> submodules happen to not have a \"master\" branch:\n>> >> >>\n>> >> >> git clone git://gitorious.org/qt/qt5.git qt5\n>> >> >> cd qt5\n>> >> >> git submodule init qtbase\n>> >> >> git submodule update\n>> >> >>\n>> >> >> In current master, the last command fails with the following output:\n>> >> >\n>> >> > ... and with a bug-free system, what does it do instead? Just clone\n>> >> > 'qtbase' and make a detached-head checkout at the commit recorded in\n>> >> > the superproject's tree, or something else?\n>> >>\n>> >> After reverting 23d25e48f5ead73 on current master it clones 'qtbase'\n>> >> nicely with a detached HEAD.\n\n...which is exactly the behaviour I (and the Qt project - I assume) expected.\n\n>> > Fixing this for initial update clone is pretty easy, we just need to\n>> > unset start_point before calling module_clone if\n>> > submodule..branch is not set.\n>>\n>> There is this bit for \"update\" in git-submodule.txt:\n>>\n>> For updates that clone missing submodules, checkout-mode updates\n>> will create submodules with detached HEADs; all other modes will\n>> create submodules with a local branch named after\n>> submodule..branch.\n>>\n>> [side note] Isn't that a typo of submodule..branch?\n>\n> Yep, thats is a typo. Trevor will you fix that as well? Or how should be\n> do that? Since its just such a small change.\n>\n>> So the proposed change is to make the part before semicolon true?\n>> If we are not newly cloning (because we already have it), if the\n>> submodule..branch is not set *OR* refers to a branch that does\n>> not even exist, shouldn't we either (1) abort as an error, or (2) do\n>> the same and detach?\n>\n> I would expect \"(1) abort as an error\" since the user is not getting what\n> he would expect.\n\nFWIW, here is the behaviour I would expect from \"git submodule update\":\n\n - In checkout-mode, if submodule..branch is not set, we should\n_always_ detach. Whether or not the submodule is already cloned does\nnot matter.\n\n - In rebase/merge-mode, if submodule..branch is not set, we\nshould _always_ abort with an error.\n\n - If submodule..branch is set - but the branch it refers to\ndoes not exist - we should _always_ abort with an error. The current\ncheckout/rebase/merge-mode does not matter.\n\nIn other words, submodule..branch is _necessary_ in rebase/merge\nmode, but _optional_ in checkout-mode (its absence indicating that we\nshould detach).\n\n>> > However, that's just going to\n>> > push remote branch ambiguity problems back to the --remote update\n>> > functionality. What should happen when submodule..branch is not\n>> > set and you run a --remote update, which has used:\n>> >\n>> > git rev-parse \"${remote_name}/${branch}\"\n>> >\n>> > since the submodule..branch setting was introduced in 06b1abb\n>> > (submodule update: add --remote for submodule's upstream changes,\n>> > 2012-12-19)?\n>>\n>> Isn't --remote about following one specific branch the user who\n>> issues that command has in mind? If you as the end user did not\n>> give any indication which branch you meant, e.g. by leaving the\n>> submodule..branch empty, shouldn't that be diagnosed as an\n>> error?\n>\n> Well to simplify things there was this fallback to origin/master\n> (similar to the master branch we create on init) since that is a branch\n> which many projects have.\n\nI think the analogy to \"the master branch we create on init\" is false.\nA better analogy is running \"git pull\" or \"git pull -rebase\" in a\nbranch where branch..merge has not yet been set. And this\ncurrently fails with \"Please specify which branch you want to merge\nwith.\" So I would be inclined to agree with Junio here: We should\nerror out.\n\n> E.g. for the users that share one central\n> server and just directly commit, push and pull to/from master. They\n> would have an easy way to start working in a submodule, by simply saying\n> --remote and then committing to master. At least that is what I\n> imagine.\n\nIf there are compelling arguments for providing a default fallback\n(and I'm not sure the above argument is enough), I say we should\nrather follow clone's lead, and use the submodule's upstream's HEAD,\ninstead of blindly assuming \"origin/master\" to be present. I expect in\nmost cases where \"origin/master\" happens to be the Right Answer, using\nthe submodule's upstream's HEAD will yield the same result.\n\n>> > gitmodules(5) is pretty clear that 'submodule..branch' defaults\n>> > to master (and not upstream's HEAD), do we want to adjust this at the\n>> > same time?\n>>\n>> That may be likely. If the value set to a configuration variable\n>> causes an established behaviour of a program change a lot, silently\n>> defaulting that variable to something many people are expected to\n>> have (e.g. 'master') would likely to cause a usability regression.\n>\n> IMO this branch configuration should completely ignored in the default,\n> non --remote, usage. Since we simply checkout a specific SHA1 in this\n> case, that should be possible.\n\nYes. Checkout-mode with no submodule..branch configured should\nalways detach.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"237959","messageId":"CALKQrgeLY2ziW2jOoWgNcsBR6EE4rnmkYN6Z1iiGXDtiECE8og@mail.gmail.com","threadId":"36302","inReplyTo":"5334AC59.7010605@web.de","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-03-27T23:27:29Z","receivedAt":"2014-03-27T23:27:29Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thu, Mar 27, 2014 at 11:55 PM, Jens Lehmann wrote:\n> Am 27.03.2014 19:30, schrieb Junio C Hamano:\n>> - For a repository that does not have that \"branch\" thing\n>> configured, the doc says that it will default to 'master'.\n>>\n>> I do not think this was brought up during the review, but is it a\n>> sensible default if the project does not even have that branch?\n>>\n>> What are viable alternatives?\n>>\n>> - use 'master' and fail just the way Johan saw?\n>>\n>> - use any random branch that happens to be at the same commit as\n>> what is being checked out?\n>>\n>> - use the branch \"clone\" for the submodule repository saw the\n>> upstream was pointing at with its HEAD?\n>>\n>> - something else?\n>\n> Good question. Me thinks that when a superproject doesn't have\n> 'branch' configured and does set 'update' to something other than\n> 'checkout' for a submodule it should better make sure 'master'\n> is a valid branch in there. Everything else sounds like a\n> misconfiguration on the superproject's part that warrants an\n> error. But I may be wrong here as I only use 'checkout' together\n> with a detached HEADs myself. Comments welcome.\n\nI believe unset 'branch' and 'update' != 'checkout' is somewhat\nanalogous to unset branch..merge while pulling. I.e. \"you have\ntold me to merge/rebase, but you have not told me against which\nbranch, therefore error out\".\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"237972","messageId":"20140328023339.GC25485@odin.tremily.us","threadId":"36302","inReplyTo":"5334AC59.7010605@web.de","subject":"Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-28T02:33:39Z","receivedAt":"2014-03-28T02:33:39Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Mar 27, 2014 at 11:55:21PM +0100, Jens Lehmann wrote:\n> Me thinks that when a superproject doesn't have 'branch' configured\n> and does set 'update' to something other than 'checkout' for a\n> submodule it should better make sure 'master' is a valid branch in\n> there. Everything else sounds like a misconfiguration on the\n> superproject's part that warrants an error.\n\nsubmodule..branch should only matter for --remote updates (and\nthe initial clone, which is a special case of remote update). So\nhaving an alternative update mode and no submodule..branch *is*\na valid configuration. It says:\n\n* I want to integrate local submodule commits with superproject\n gitlink changes using the submodule..update strategy.\n* I never use --remote updates, so I haven't bothered to setup\n submodule..branch.\n\nI can imagine folks using a workflow like that. And I think erroring\nout if they *do* try a --remote update shouldn't be too surprising for\nthem.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237974","messageId":"20140328030556.GD25485@odin.tremily.us","threadId":"36302","inReplyTo":"CALKQrgdAhe0AKk51=__fDWX9QqFH=WVCO=gU+mtO6sb250==0A@mail.gmail.com","subject":"Re: Re: Possible regression in master? (submodules without a \"master\" branch)","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-28T03:05:56Z","receivedAt":"2014-03-28T03:05:56Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:\n> On Thu, Mar 27, 2014 at 9:27 PM, Heiko Voigt wrote:\n> > On Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:\n> >> There is this bit for \"update\" in git-submodule.txt:\n> >>\n> >> For updates that clone missing submodules, checkout-mode\n> >> updates will create submodules with detached HEADs; all other\n> >> modes will create submodules with a local branch named after\n> >> submodule..branch.\n> >>\n> >> …\n> >> So the proposed change is to make the part before semicolon true?\n> >> If we are not newly cloning (because we already have it), if the\n> >> submodule..branch is not set *OR* refers to a branch that\n> >> does not even exist, shouldn't we either (1) abort as an error,\n> >> or (2) do the same and detach?\n> >\n> > I would expect \"(1) abort as an error\" since the user is not\n> > getting what he would expect.\n\nBranch-attachment is mostly a function of submodule..update, not\na function of submodule..branch. We could certainly interpret a\nmissing submodule..branch as:\n\n* Use the subproject's HEAD for the initial clone (clear start_point\n in cmd_update if submodule.\"$name\".branch is not set).\n* Don't change the branch name on subsequent local updates (what we\n already do).\n* Do $something if the user tries a --remote update.\n\nI just don't know what that $something should be.\n\n> FWIW, here is the behaviour I would expect from \"git submodule\n> update\":\n> \n> - In checkout-mode, if submodule..branch is not set, we\n> should _always_ detach. Whether or not the submodule is already\n> cloned does not matter.\n\nAgreed, checkout-mode should *always* detach the submodule's HEAD.\n\n> - In rebase/merge-mode, if submodule..branch is not set, we\n> should _always_ abort with an error.\n\nWhy? Can't we mimic clone and use the remote's HEAD (for --remote\nupdates)? That seems more intuitive to me. For local updates, we're\njust integrating the gitlinked commit with the submodule's HEAD, and\nyou don't need submodule..branch for that at all.\n\n> - If submodule..branch is set - but the branch it refers to\n> does not exist - we should _always_ abort with an error. The current\n> checkout/rebase/merge-mode does not matter.\n\nSounds good to me, and should match the current functionality.\n\n> In other words, submodule..branch is _necessary_ in\n> rebase/merge mode, but _optional_ in checkout-mode (its absence\n> indicating that we should detach).\n\nThe main trigger for “we should detach” is the update mode\n(checkout-mode detaches, all others integrate with the submodule's\nHEAD (without changing submodule branches). You only need\nsubmodule..branch for determining which *remote* commit you're\ntrying to integrate (or clone from). HEAD, master, and “die\nscreaming” all sound like reasonable defaults in that case. Deciding\nbetween them is a policy/UI decision, not a technical decision.\n\n> >> > gitmodules(5) is pretty clear that 'submodule..branch'\n> >> > defaults to master (and not upstream's HEAD), do we want to\n> >> > adjust this at the same time?\n> >>\n> >> That may be likely. If the value set to a configuration variable\n> >> causes an established behaviour of a program change a lot,\n> >> silently defaulting that variable to something many people are\n> >> expected to have (e.g. 'master') would likely to cause a\n> >> usability regression.\n> >\n> > IMO this branch configuration should completely ignored in the\n> > default, non --remote, usage. Since we simply checkout a specific\n> > SHA1 in this case, that should be possible.\n> \n> Yes. Checkout-mode with no submodule..branch configured should\n> always detach.\n\nExcept for the initial clone (where it's easy to fix),\nsubmodule..branch *is* ignored in non --remote updates.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237976","messageId":"c66d89d854407469b6fd223213a09e5d60eeec0a.1395977055.git.wking@tremily.us","threadId":"36302","inReplyTo":"20140328030556.GD25485@odin.tremily.us","subject":"[RFC] submodule: change submodule..branch default from master to HEAD","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-28T03:36:59Z","receivedAt":"2014-03-28T03:36:59Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"gitmodule(5) mentioned 'master' as the default remote branch, but\nfolks using checkout-style updates are unlikely to care which upstream\nbranch their commit comes from (they only care that the clone fetches\nthat commit). If they haven't set submodule..branch, it makes\nmore sense to mirror 'git clone' and use the subproject's HEAD than to\ndefault to 'master' (which may not even exist).\n\nAfter the initial clone, subsequent updates may be local or remote.\nLocal updates (integrating gitlink changes) have no need to fetch a\nspecific remote branch, and get along just fine without\nsubmodule..branch. Remote updates do need a remote branch, but\nHEAD works as well here as it did for the initial clone.\n\nReported-by: Johan Herland \nSigned-off-by: W. Trevor King \n---\nThis still needs tests, but it gets through the following fine:\n\n rm -rf superproject subproject &&\n mkdir subproject &&\n (cd subproject &&\n git init &&\n echo 'Subproject' > README &&\n git add README &&\n git commit -m 'Subproject commit' &&\n git branch -m master next\n ) &&\n mkdir superproject &&\n (cd superproject &&\n git init &&\n git submodule add ../subproject submod &&\n git commit -am 'Add submod'\n )\n (cd subproject &&\n echo 'work work work' >> README &&\n git commit -am 'Subproject commit 2'\n ) &&\n (cd superproject &&\n git submodule update --remote &&\n git commit -am 'Add submod'\n )\n\nThe main drawback to this approach is that we're changing a default,\nbut I agree with John's:\n\nOn Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:\n> I expect in most cases where \"origin/master\" happens to be the Right\n> Answer, using the submodule's upstream's HEAD will yield the same\n> result.\n\nso the default-change may not be particularly intrusive.\n\nCheers,\nTrevor\n\n Documentation/git-submodule.txt | 2 +-\n Documentation/gitmodules.txt | 5 +++--\n git-submodule.sh | 11 ++++++++---\n 3 files changed, 12 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 46c1eeb..c485a17 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -284,7 +284,7 @@ OPTIONS\n \tthe superproject's recorded SHA-1 to update the submodule, use the\n \tstatus of the submodule's remote-tracking branch. The remote used\n \tis branch's remote (`branch..remote`), defaulting to `origin`.\n-\tThe remote branch used defaults to `master`, but the branch name may\n+\tThe remote branch used defaults to `HEAD`, but the branch name may\n \tbe overridden by setting the `submodule..branch` option in\n \teither `.gitmodules` or `.git/config` (with `.git/config` taking\n \tprecedence).\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex f539e3f..1aecce9 100644\n--- a/Documentation/gitmodules.txt\n+++ b/Documentation/gitmodules.txt\n@@ -53,8 +53,9 @@ submodule..update::\n \n submodule..branch::\n \tA remote branch name for tracking updates in the upstream submodule.\n-\tIf the option is not specified, it defaults to 'master'. See the\n-\t`--remote` documentation in linkgit:git-submodule[1] for details.\n+\tIf the option is not specified, it defaults to the subproject's\n+\tHEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n+\tfor details.\n +\n This branch name is also used for the local branch created by\n non-checkout cloning updates. See the `update` documentation in\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 6135cfa..5f08e6c 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -819,8 +819,8 @@ cmd_update()\n \t\tname=$(module_name \"$sm_path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n \t\tconfig_branch=$(get_submodule_config \"$name\" branch)\n-\t\tbranch=\"${config_branch:-master}\"\n-\t\tlocal_branch=\"$branch\"\n+\t\tbranch=\"${config_branch:-HEAD}\"\n+\t\tlocal_branch=\"$config_branch\"\n \t\tif ! test -z \"$update\"\n \t\tthen\n \t\t\tupdate_module=$update\n@@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?\")\"\n \n \t\tif ! test -d \"$sm_path\"/.git -o -f \"$sm_path\"/.git\n \t\tthen\n-\t\t\tstart_point=\"origin/${branch}\"\n+\t\t\tif test -n \"$config_branch\"\n+\t\t\tthen\n+\t\t\t\tstart_point=\"origin/$branch\"\n+\t\t\telse\n+\t\t\t\tstart_point=\"\"\n+\t\t\tfi\n \t\t\tmodule_clone \"$sm_path\" \"$name\" \"$url\" \"$reference\" \"$depth\" \"$start_point\" \"$local_branch\" || exit\n \t\t\tcloned_modules=\"$cloned_modules;$name\"\n \t\t\tsubsha1=\n-- \n1.9.1.352.gd393d14.dirty\n"},{"id":"237977","messageId":"CAPig+cT7tmxvYz+sLQY68SgF6osM+pAj-gFb7xvyuH+Gnw5xrg@mail.gmail.com","threadId":"36302","inReplyTo":"c66d89d854407469b6fd223213a09e5d60eeec0a.1395977055.git.wking@tremily.us","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-28T03:43:47Z","receivedAt":"2014-03-28T03:43:47Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:\n> gitmodule(5) mentioned 'master' as the default remote branch, but\n> folks using checkout-style updates are unlikely to care which upstream\n> branch their commit comes from (they only care that the clone fetches\n> that commit). If they haven't set submodule..branch, it makes\n> more sense to mirror 'git clone' and use the subproject's HEAD than to\n> default to 'master' (which may not even exist).\n>\n> After the initial clone, subsequent updates may be local or remote.\n> Local updates (integrating gitlink changes) have no need to fetch a\n> specific remote branch, and get along just fine without\n> submodule..branch. Remote updates do need a remote branch, but\n> HEAD works as well here as it did for the initial clone.\n>\n> Reported-by: Johan Herland \n> Signed-off-by: W. Trevor King \n> ---\n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index 46c1eeb..c485a17 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -284,7 +284,7 @@ OPTIONS\n> the superproject's recorded SHA-1 to update the submodule, use the\n> status of the submodule's remote-tracking branch. The remote used\n> is branch's remote (`branch..remote`), defaulting to `origin`.\n> - The remote branch used defaults to `master`, but the branch name may\n> + The remote branch used defaults to `HEAD`, but the branch name may\n> be overridden by setting the `submodule..branch` option in\n> either `.gitmodules` or `.git/config` (with `.git/config` taking\n> precedence).\n> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\n> index f539e3f..1aecce9 100644\n> --- a/Documentation/gitmodules.txt\n> +++ b/Documentation/gitmodules.txt\n> @@ -53,8 +53,9 @@ submodule..update::\n>\n> submodule..branch::\n> A remote branch name for tracking updates in the upstream submodule.\n> - If the option is not specified, it defaults to 'master'. See the\n> - `--remote` documentation in linkgit:git-submodule[1] for details.\n> + If the option is not specified, it defaults to the subproject's\n\nDid you mean s/subproject/submodule/ ?\n\n> + HEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n> + for details.\n> +\n> This branch name is also used for the local branch created by\n> non-checkout cloning updates. See the `update` documentation in\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 6135cfa..5f08e6c 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -819,8 +819,8 @@ cmd_update()\n> name=$(module_name \"$sm_path\") || exit\n> url=$(git config submodule.\"$name\".url)\n> config_branch=$(get_submodule_config \"$name\" branch)\n> - branch=\"${config_branch:-master}\"\n> - local_branch=\"$branch\"\n> + branch=\"${config_branch:-HEAD}\"\n> + local_branch=\"$config_branch\"\n> if ! test -z \"$update\"\n> then\n> update_module=$update\n> @@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?\")\"\n>\n> if ! test -d \"$sm_path\"/.git -o -f \"$sm_path\"/.git\n> then\n> - start_point=\"origin/${branch}\"\n> + if test -n \"$config_branch\"\n> + then\n> + start_point=\"origin/$branch\"\n> + else\n> + start_point=\"\"\n> + fi\n> module_clone \"$sm_path\" \"$name\" \"$url\" \"$reference\" \"$depth\" \"$start_point\" \"$local_branch\" || exit\n> cloned_modules=\"$cloned_modules;$name\"\n> subsha1=\n> --\n> 1.9.1.352.gd393d14.dirty\n"},{"id":"237979","messageId":"20140328035255.GF25485@odin.tremily.us","threadId":"36302","inReplyTo":"CAPig+cT7tmxvYz+sLQY68SgF6osM+pAj-gFb7xvyuH+Gnw5xrg@mail.gmail.com","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-28T03:52:55Z","receivedAt":"2014-03-28T03:52:55Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote:\n> On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:\n> > submodule..branch::\n> > A remote branch name for tracking updates in the upstream submodule.\n> > - If the option is not specified, it defaults to 'master'. See the\n> > - `--remote` documentation in linkgit:git-submodule[1] for details.\n> > + If the option is not specified, it defaults to the subproject's\n> \n> Did you mean s/subproject/submodule/ ?\n> \n> > + HEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n> > + for details.\n\nNo the remote branch is in the upstream subproject. I suppose I meant\n“the submodule's remote-tracking branch following the upstream\nsubproject's HEAD which we just fetched so it's fairly current” ;).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"237980","messageId":"20140328035827.GG25485@odin.tremily.us","threadId":"36302","inReplyTo":"20140328035255.GF25485@odin.tremily.us","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-28T03:58:27Z","receivedAt":"2014-03-28T03:58:27Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:\n> On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote:\n> > On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:\n> > > submodule..branch::\n> > > A remote branch name for tracking updates in the upstream submodule.\n> > > - If the option is not specified, it defaults to 'master'. See the\n> > > - `--remote` documentation in linkgit:git-submodule[1] for details.\n> > > + If the option is not specified, it defaults to the subproject's\n> > \n> > Did you mean s/subproject/submodule/ ?\n> > \n> > > + HEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n> > > + for details.\n> \n> No the remote branch is in the upstream subproject. I suppose I meant\n> “the submodule's remote-tracking branch following the upstream\n> subproject's HEAD which we just fetched so it's fairly current” ;).\n\nHmm, maybe we should change the existing “upstream submodule” to\n“upstream subproject” for consistency?\n\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"238013","messageId":"5335AA0E.7000001@web.de","threadId":"36302","inReplyTo":"20140328035827.GG25485@odin.tremily.us","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-28T16:57:50Z","receivedAt":"2014-03-28T16:57:50Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.03.2014 04:58, schrieb W. Trevor King:\n> On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:\n>> On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote:\n>>> On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:\n>>>> submodule..branch::\n>>>> A remote branch name for tracking updates in the upstream submodule.\n>>>> - If the option is not specified, it defaults to 'master'. See the\n>>>> - `--remote` documentation in linkgit:git-submodule[1] for details.\n>>>> + If the option is not specified, it defaults to the subproject's\n>>>\n>>> Did you mean s/subproject/submodule/ ?\n>>>\n>>>> + HEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n>>>> + for details.\n>>\n>> No the remote branch is in the upstream subproject. I suppose I meant\n>> “the submodule's remote-tracking branch following the upstream\n>> subproject's HEAD which we just fetched so it's fairly current” ;).\n> \n> Hmm, maybe we should change the existing “upstream submodule” to\n> “upstream subproject” for consistency?\n\nFor me it's still an \"upstream submodule\" ...\n"},{"id":"238017","messageId":"20140328171059.GJ25485@odin.tremily.us","threadId":"36302","inReplyTo":"5335AA0E.7000001@web.de","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-28T17:10:59Z","receivedAt":"2014-03-28T17:10:59Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote:\n> Am 28.03.2014 04:58, schrieb W. Trevor King:\n> > On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:\n> >> No the remote branch is in the upstream subproject. I suppose I meant\n> >> “the submodule's remote-tracking branch following the upstream\n> >> subproject's HEAD which we just fetched so it's fairly current” ;).\n> > \n> > Hmm, maybe we should change the existing “upstream submodule” to\n> > “upstream subproject” for consistency?\n> \n> For me it's still an \"upstream submodule\" ...\n\nWe have a few existing “[upstream] subproject” references though. I\nprefer subproject, because the submodule's upstream repository is\nlikely a bare repo and not a submodule itself. It's also possible\n(likely?) that the upstream repository is a stand-alone project, and\nnot designed to always be a submodule. However, “upstream submodule”\nand “submodule's upstream” are both clear enough, and if they're the\nconsensus phrasing, I'd rather standardize on them than jump back and\nforth between phrasings in the docs. I can write up a patch that\nshifts us to consistently use one form, once we decide what that\nshould be (although I'm happy to let someone else write the patch too\n;).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"238021","messageId":"xmqqk3beb5bl.fsf@gitster.dls.corp.google.com","threadId":"36302","inReplyTo":"5335AA0E.7000001@web.de","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-28T17:28:46Z","receivedAt":"2014-03-28T17:28:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Am 28.03.2014 04:58, schrieb W. Trevor King:\n>> On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:\n>>> On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote:\n>>>> On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:\n>>>>> submodule..branch::\n>>>>> A remote branch name for tracking updates in the upstream submodule.\n>>>>> - If the option is not specified, it defaults to 'master'. See the\n>>>>> - `--remote` documentation in linkgit:git-submodule[1] for details.\n>>>>> + If the option is not specified, it defaults to the subproject's\n>>>>\n>>>> Did you mean s/subproject/submodule/ ?\n>>>>\n>>>>> + HEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n>>>>> + for details.\n>>>\n>>> No the remote branch is in the upstream subproject. I suppose I meant\n>>> “the submodule's remote-tracking branch following the upstream\n>>> subproject's HEAD which we just fetched so it's fairly current” ;).\n>> \n>> Hmm, maybe we should change the existing “upstream submodule” to\n>> “upstream subproject” for consistency?\n>\n> For me it's still an \"upstream submodule\" ...\n\nI inherited the habit of saying \"submodule\" vs \"superproject\" from\nLinus (I think) during the very early days, and there is no such\nthing as \"subproject\" or \"supermodule\" in my vocabulary.\n\nJust one documentation-reader's opinion, not an edict from the\nmaintainer.\n"},{"id":"238133","messageId":"5339C29B.5030301@web.de","threadId":"36302","inReplyTo":"20140328171059.GJ25485@odin.tremily.us","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-31T19:31:39Z","receivedAt":"2014-03-31T19:31:39Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.03.2014 18:10, schrieb W. Trevor King:\n> On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote:\n>> Am 28.03.2014 04:58, schrieb W. Trevor King:\n>>> On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:\n>>>> No the remote branch is in the upstream subproject. I suppose I meant\n>>>> “the submodule's remote-tracking branch following the upstream\n>>>> subproject's HEAD which we just fetched so it's fairly current” ;).\n>>>\n>>> Hmm, maybe we should change the existing “upstream submodule” to\n>>> “upstream subproject” for consistency?\n>>\n>> For me it's still an \"upstream submodule\" ...\n> \n> We have a few existing “[upstream] subproject” references though. I\n> prefer subproject, because the submodule's upstream repository is\n> likely a bare repo and not a submodule itself. It's also possible\n> (likely?) that the upstream repository is a stand-alone project, and\n> not designed to always be a submodule. However, “upstream submodule”\n> and “submodule's upstream” are both clear enough, and if they're the\n> consensus phrasing, I'd rather standardize on them than jump back and\n> forth between phrasings in the docs. I can write up a patch that\n> shifts us to consistently use one form, once we decide what that\n> should be (although I'm happy to let someone else write the patch too\n> ;).\n\nApart from the RelNotes there are only seven places in the\nDocumentation directory where the term \"subproject\" is used:\n\n- Two in git-submodule.txt (which are those you recently added in\n the series that introduced the regression and would be gone if\n we revert that)\n\n- One in git-write-tree.txt (but as I understand it the --prefix\n option can be used to record tree objects for other tools too,\n so the more generic term subproject looks OK to me there)\n\n- Four occurrences in user-manual.txt describing the diff format\n for submodules (which I assume will always stay \"[+-]Subproject\"\n for backwards compatibility reasons)\n\nIf we do not revert your series I'll be happy to write up a patch\nreplacing the two usages of subproject in git-submodule.txt ;-)\n"},{"id":"238134","messageId":"5339C36B.5020502@web.de","threadId":"36302","inReplyTo":"c66d89d854407469b6fd223213a09e5d60eeec0a.1395977055.git.wking@tremily.us","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-31T19:35:07Z","receivedAt":"2014-03-31T19:35:07Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.03.2014 04:36, schrieb W. Trevor King:\n> gitmodule(5) mentioned 'master' as the default remote branch, but\n> folks using checkout-style updates are unlikely to care which upstream\n> branch their commit comes from (they only care that the clone fetches\n> that commit). If they haven't set submodule..branch, it makes\n> more sense to mirror 'git clone' and use the subproject's HEAD than to\n> default to 'master' (which may not even exist).\n> \n> After the initial clone, subsequent updates may be local or remote.\n> Local updates (integrating gitlink changes) have no need to fetch a\n> specific remote branch, and get along just fine without\n> submodule..branch. Remote updates do need a remote branch, but\n> HEAD works as well here as it did for the initial clone.\n> \n> Reported-by: Johan Herland \n> Signed-off-by: W. Trevor King \n> ---\n> This still needs tests, but it gets through the following fine:\n> \n> rm -rf superproject subproject &&\n> mkdir subproject &&\n> (cd subproject &&\n> git init &&\n> echo 'Subproject' > README &&\n> git add README &&\n> git commit -m 'Subproject commit' &&\n> git branch -m master next\n> ) &&\n> mkdir superproject &&\n> (cd superproject &&\n> git init &&\n> git submodule add ../subproject submod &&\n> git commit -am 'Add submod'\n> )\n> (cd subproject &&\n> echo 'work work work' >> README &&\n> git commit -am 'Subproject commit 2'\n> ) &&\n> (cd superproject &&\n> git submodule update --remote &&\n> git commit -am 'Add submod'\n> )\n> \n> The main drawback to this approach is that we're changing a default,\n> but I agree with John's:\n> \n> On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:\n>> I expect in most cases where \"origin/master\" happens to be the Right\n>> Answer, using the submodule's upstream's HEAD will yield the same\n>> result.\n> \n> so the default-change may not be particularly intrusive.\n\nI'd prefer a solution that doesn't change any defaults for the\ncheckout use case (again). Maybe it is a better route to revert\nthis series, then add tests describing the current behavior for\ncheckout submodules as a next step before adding the branch mode\nfor rebase and merge users again?\n\n> Cheers,\n> Trevor\n> \n> Documentation/git-submodule.txt | 2 +-\n> Documentation/gitmodules.txt | 5 +++--\n> git-submodule.sh | 11 ++++++++---\n> 3 files changed, 12 insertions(+), 6 deletions(-)\n> \n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index 46c1eeb..c485a17 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -284,7 +284,7 @@ OPTIONS\n> \tthe superproject's recorded SHA-1 to update the submodule, use the\n> \tstatus of the submodule's remote-tracking branch. The remote used\n> \tis branch's remote (`branch..remote`), defaulting to `origin`.\n> -\tThe remote branch used defaults to `master`, but the branch name may\n> +\tThe remote branch used defaults to `HEAD`, but the branch name may\n> \tbe overridden by setting the `submodule..branch` option in\n> \teither `.gitmodules` or `.git/config` (with `.git/config` taking\n> \tprecedence).\n> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\n> index f539e3f..1aecce9 100644\n> --- a/Documentation/gitmodules.txt\n> +++ b/Documentation/gitmodules.txt\n> @@ -53,8 +53,9 @@ submodule..update::\n> \n> submodule..branch::\n> \tA remote branch name for tracking updates in the upstream submodule.\n> -\tIf the option is not specified, it defaults to 'master'. See the\n> -\t`--remote` documentation in linkgit:git-submodule[1] for details.\n> +\tIf the option is not specified, it defaults to the subproject's\n> +\tHEAD. See the `--remote` documentation in linkgit:git-submodule[1]\n> +\tfor details.\n> +\n> This branch name is also used for the local branch created by\n> non-checkout cloning updates. See the `update` documentation in\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 6135cfa..5f08e6c 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -819,8 +819,8 @@ cmd_update()\n> \t\tname=$(module_name \"$sm_path\") || exit\n> \t\turl=$(git config submodule.\"$name\".url)\n> \t\tconfig_branch=$(get_submodule_config \"$name\" branch)\n> -\t\tbranch=\"${config_branch:-master}\"\n> -\t\tlocal_branch=\"$branch\"\n> +\t\tbranch=\"${config_branch:-HEAD}\"\n> +\t\tlocal_branch=\"$config_branch\"\n> \t\tif ! test -z \"$update\"\n> \t\tthen\n> \t\t\tupdate_module=$update\n> @@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?\")\"\n> \n> \t\tif ! test -d \"$sm_path\"/.git -o -f \"$sm_path\"/.git\n> \t\tthen\n> -\t\t\tstart_point=\"origin/${branch}\"\n> +\t\t\tif test -n \"$config_branch\"\n> +\t\t\tthen\n> +\t\t\t\tstart_point=\"origin/$branch\"\n> +\t\t\telse\n> +\t\t\t\tstart_point=\"\"\n> +\t\t\tfi\n> \t\t\tmodule_clone \"$sm_path\" \"$name\" \"$url\" \"$reference\" \"$depth\" \"$start_point\" \"$local_branch\" || exit\n> \t\t\tcloned_modules=\"$cloned_modules;$name\"\n> \t\t\tsubsha1=\n> \n"},{"id":"238141","messageId":"20140331203825.GH19236@odin.tremily.us","threadId":"36302","inReplyTo":"5339C36B.5020502@web.de","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-03-31T20:38:25Z","receivedAt":"2014-03-31T20:38:25Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Mar 31, 2014 at 09:35:07PM +0200, Jens Lehmann wrote:\n> Am 28.03.2014 04:36, schrieb W. Trevor King:\n> > The main drawback to this approach is that we're changing a default,\n> > but I agree with John's:\n> > \n> > On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:\n> >> I expect in most cases where \"origin/master\" happens to be the\n> >> Right Answer, using the submodule's upstream's HEAD will yield\n> >> the same result.\n> > \n> > so the default-change may not be particularly intrusive.\n> \n> I'd prefer a solution that doesn't change any defaults for the\n> checkout use case (again). Maybe it is a better route to revert\n> this series, then add tests describing the current behavior for\n> checkout submodules as a next step before adding the branch mode\n> for rebase and merge users again?\n\nThe change in defaults should only adversely effect users who:\n\n* don't configure submodule..branch,\n* use --remote updates,\n* expect them to pull the master branch of the submodule's upstream, and\n* have an upstream whose HEAD doesn't point at master.\n\nSince 23d25e4 (submodule: explicit local branch creation in\nmodule_clone, 2014-01-26), we adversely effects users (regardless of\nupdate strategy) who:\n\n* don't configure submodule..branch, and\n* update-clone from a submodule upstream that doesn't have a master branch.\n\nBut with this patch we'll fix that. Before 23d25e4, we adversly\naffected users who:\n\n* used non-checkout update strategies, and\n* wanted an attached HEAD after update-clones.\n\nAll of these were easy to work around, with either:\n\n $ git config submodule.$name.branch $branch\n\nor:\n\n $ cd $submod\n $ git checkout $branch\n\nI'm fine reverting 23d25e4 if we want to kick it around some more, but\nI have trouble imagining a future UI that works for both:\n\n* users that want --remote to pull master even though upstream's HEAD\n points elsewhere, and\n* users that want --remote to pull HEAD because upstream doesn't have\n a master branch,\n\nif neither of those users are willing to configure an explicit\nsubmodule..branch.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"238143","messageId":"xmqq38hy5c7v.fsf@gitster.dls.corp.google.com","threadId":"36302","inReplyTo":"5339C36B.5020502@web.de","subject":"Re: [RFC] submodule: change submodule..branch default from master to HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-31T20:45:24Z","receivedAt":"2014-03-31T20:45:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> I'd prefer a solution that doesn't change any defaults for the\n> checkout use case (again). Maybe it is a better route to revert\n> this series, then add tests describing the current behavior for\n> checkout submodules as a next step before adding the branch mode\n> for rebase and merge users again?\n\nSounds like a good idea to revert the entire series, as that would\ngive us longer to think the whole thing through. It would certainly\navoid unexpected fallout in 2.0 where we already have other changes,\nall of which are known/designed to be backward incompatible with a\nset of carefully planned transition plans. This submodule change\nmay have meant well, but does not seem to sit well together with\nthese other changes.\n\nPerhaps in 2.1 or 2.2.\n"}]}