{"thread":{"id":"35624","subject":"Re: [RFC v2] submodule: Respect requested branch on all clones","startedAt":"2014-01-07T21:37:39Z","lastAt":"2014-01-07T21:51:34Z","messageCount":2,"participants":["W. Trevor King","Francesco Pretto"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"232864","messageId":"20140107213739.GA29954@odin.tremily.us","threadId":"35624","inReplyTo":"CALas-iizoBjTu2KSXsZExNeLz5hxbzoNNGgYLMP9SmDH+kt9Vw@mail.gmail.com","subject":"Re: [RFC v2] submodule: Respect requested branch on all clones","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-01-07T21:37:39Z","receivedAt":"2014-01-07T21:37:39Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:\n> 2014/1/7 W. Trevor King <wking@tremily.us>:\n> >> Trevor, maybe it was not clear. But I wanted to say:\n> >>\n> >> \" I fully support *Trevor's* patch...\" :)\n> >\n> > Which I appreciate ;).  I still though I should point out that my\n> > patch *confuses* the role of submodule.<name>.branch :p.\n> \n> You are welcome. Also, at your wish, can you please reply also in\n> public?\n\nHere you go.\n\nI'd be happy to hear ideas about superproject-branch-specific local\noverrides to a hypothetical submodule.<name>.local-branch, in the\nevent that a developer doesn't like a default set in .gitmodules.  If\nI could think of a way to do that, we could avoid this heuristic\napproach, and make the local submodule.<name>.local-branch\nvs. remote-tracking submodule.<name>.branch distinction more obvious.\n\nIt would also be nice if submodule.<name>.branch was just an initial\nsetup-time and detached-HEAD default.  If the submodule is on a branch\nit would make more sense to use the checked-out branch's @{upstream}.\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":"232866","messageId":"CALas-iiH0GCwy9WMWxBSGbUykwAKikaLUhfdDUbETv91QuM-7g@mail.gmail.com","threadId":"35624","inReplyTo":"20140107213739.GA29954@odin.tremily.us","subject":"Re: [RFC v2] submodule: Respect requested branch on all clones","fromName":"Francesco Pretto","fromEmail":"ceztko@gmail.com","sentAt":"2014-01-07T21:51:34Z","receivedAt":"2014-01-07T21:51:34Z","isPatch":false,"sender":{"key":"ceztko@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3037449?v=4"},"body":"2014/1/7 W. Trevor King <wking@tremily.us>:\n>\n> I'd be happy to hear ideas about superproject-branch-specific local\n> overrides to a hypothetical submodule.<name>.local-branch, in the\n> event that a developer doesn't like a default set in .gitmodules.  If\n> I could think of a way to do that, we could avoid this heuristic\n> approach, and make the local submodule.<name>.local-branch\n> vs. remote-tracking submodule.<name>.branch distinction more obvious.\n>\n\nUh, I think you got it wrong in the other thread: I didn't proposed\nsuch feature. I just wanted the attached submodule use case to be\nsupported and of course \"--branch means attached\" is even easier to\nget this.\n"}]}