{"thread":{"id":"34295","subject":"git clone -b","startedAt":"2013-06-28T11:59:51Z","lastAt":"2013-07-03T10:01:19Z","messageCount":10,"participants":["Stefan Näwe","Fredrik Gustafsson","Junio C Hamano","Phil Hord","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"222166","messageId":"51CD7AB7.3040409@atlas-elektronik.com","threadId":"34295","inReplyTo":null,"subject":"git clone -b","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2013-06-28T11:59:51Z","receivedAt":"2013-06-28T11:59:51Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Hi there!\n\nIs there any reason why 'git clone -b' only takes a branch (from refs/heads/)\nor a tag (from refs/tags/) ?\n\nBackground: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\nto communicate between the 'branch integrator' (who creates the ref in refs/releases/)\nand the 'build master' who wants to build that ref. \n\nIt would be a little easier if the build master could simply say\n\n  git clone -b refs/releases/the-release-for-today URL\n\ninstead of: git clone... ; cd ... ; git fetch... ; git checkout....\n\nAny answer or even a better idea to solve that is appreciated.\n\nStefan\n-- \n----------------------------------------------------------------\n/dev/random says: Second star to the right & straight on till morning...\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\"\n"},{"id":"222167","messageId":"51CD7E7D.4040104@atlas-elektronik.com","threadId":"34295","inReplyTo":"51CD7AB7.3040409@atlas-elektronik.com","subject":"Re: git clone -b","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2013-06-28T12:15:57Z","receivedAt":"2013-06-28T12:15:57Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 28.06.2013 13:59, schrieb Stefan Näwe:\n> Hi there!\n> \n> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)\n> or a tag (from refs/tags/) ?\n> \n> Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\n> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)\n> and the 'build master' who wants to build that ref. \n> \n> It would be a little easier if the build master could simply say\n> \n>   git clone -b refs/releases/the-release-for-today URL\n> \n> instead of: git clone... ; cd ... ; git fetch... ; git checkout....\n> \n> Any answer or even a better idea to solve that is appreciated.\n> \n> Stefan\n> \n\nOh, and while at it:\n\nThis doesn't look/feel right:\n\n  $ git clone -b refs/heads/master git/.git other-git\n  Cloning into 'other-git'...\n  fatal: Remote branch refs/heads/master not found in upstream origin\n  fatal: The remote end hung up unexpectedly\n\n(where git is git's git which definitely has refs/heads/master...)\n\nStefan\n-- \n----------------------------------------------------------------\n/dev/random says: In God we trust; all else we walk through.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\"\n"},{"id":"222168","messageId":"20130628121847.GB1351@paksenarrion.iveqy.com","threadId":"34295","inReplyTo":"51CD7AB7.3040409@atlas-elektronik.com","subject":"Re: git clone -b","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-06-28T12:18:47Z","receivedAt":"2013-06-28T12:18:47Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:\n> Hi there!\n> \n> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)\n> or a tag (from refs/tags/) ?\n> \n> Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\n> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)\n> and the 'build master' who wants to build that ref. \n> \n> It would be a little easier if the build master could simply say\n> \n>   git clone -b refs/releases/the-release-for-today URL\n> \n> instead of: git clone... ; cd ... ; git fetch... ; git checkout....\n> \n> Any answer or even a better idea to solve that is appreciated.\n> \n> Stefan\n\nI don't understand what the alternative should be. You can't look in\n/refs/* because there's a lot of other stuff like bisect/remotes etc.\nthere.\n\nOf course you could add to also look in /refs/releases/ but as I\nunderstand you that a special solution for your company. Why should all\ngit users have that addition?\n\nTwo questions about your setup:\n\n\t1. Why do you always clone your repository? To me clone is a one\n\ttime operation.\n\n\t2. Why don't you tag your releases with an ordinary tag?\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"222169","messageId":"51CD8136.6090702@atlas-elektronik.com","threadId":"34295","inReplyTo":"20130628121847.GB1351@paksenarrion.iveqy.com","subject":"Re: git clone -b","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2013-06-28T12:27:34Z","receivedAt":"2013-06-28T12:27:34Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 28.06.2013 14:18, schrieb Fredrik Gustafsson:\n> On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:\n>> Hi there!\n>>\n>> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)\n>> or a tag (from refs/tags/) ?\n>>\n>> Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\n>> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)\n>> and the 'build master' who wants to build that ref. \n>>\n>> It would be a little easier if the build master could simply say\n>>\n>>   git clone -b refs/releases/the-release-for-today URL\n>>\n>> instead of: git clone... ; cd ... ; git fetch... ; git checkout....\n>>\n>> Any answer or even a better idea to solve that is appreciated.\n>>\n>> Stefan\n> \n> I don't understand what the alternative should be. You can't look in\n> /refs/* because there's a lot of other stuff like bisect/remotes etc.\n> there.\n\nWell, I tell clone exactly what I want. There is no reason try something\nfrom refs/*.\n \n> Of course you could add to also look in /refs/releases/ but as I\n> understand you that a special solution for your company. Why should all\n> git users have that addition?\n\nIt wouldn't hurt, IMHO. Maybe it would even make sense to allow any SHA-1\nto be passed to '-b'.\n \n> Two questions about your setup:\n> \n> \t1. Why do you always clone your repository? To me clone is a one\n> \ttime operation.\n\nWe would use 'git archive' if that would be submodule-aware...\n\n> \t2. Why don't you tag your releases with an ordinary tag?\n\nBecause we use that 'refs/release' thing as a hidden ref that other\ndevelopers will not see when they fetch (unless they are told to checkout\nthat particular ref).\n\nThink of using this similar to the way github uses refs/pull/*/{head,merge} \nfor their pull request mechanism.\n\nStefan\n-- \n----------------------------------------------------------------\n/dev/random says: The Definition of an Upgrade: Take old bugs out, put new ones in.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\"\n"},{"id":"222268","messageId":"51D12A0E.60709@atlas-elektronik.com","threadId":"34295","inReplyTo":"51CD7AB7.3040409@atlas-elektronik.com","subject":"Re: git clone -b","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2013-07-01T07:04:46Z","receivedAt":"2013-07-01T07:04:46Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 28.06.2013 13:59, schrieb Stefan Näwe:\n> Hi there!\n> \n> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)\n> or a tag (from refs/tags/) ?\n> \n> Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\n> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)\n> and the 'build master' who wants to build that ref. \n> \n> It would be a little easier if the build master could simply say\n> \n>   git clone -b refs/releases/the-release-for-today URL\n> \n> instead of: git clone... ; cd ... ; git fetch... ; git checkout....\n> \n> Any answer or even a better idea to solve that is appreciated.\n> \n> Stefan\n> \n\nAnyone?\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: Some people like learning Eskimo, but I can't get Inuit.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\"\n"},{"id":"222285","messageId":"7v61wui5xe.fsf@alter.siamese.dyndns.org","threadId":"34295","inReplyTo":"51D12A0E.60709@atlas-elektronik.com","subject":"Re: git clone -b","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-01T16:46:53Z","receivedAt":"2013-07-01T16:46:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:\n\n>> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)\n>> or a tag (from refs/tags/) ?\n\nBecause they are common enough, and doing the same for an arbitrary\nobject is just as easy to do something like:\n\n\tgit clone -n\n        git checkout $an_arbitrary_commit_object_name^0\n\n>> Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\n>> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)\n>> and the 'build master' who wants to build that ref. \n\nWhile I wasn't paying much attention to this, I vaguely recall that\npeople pointed out that using a fresh clone every time may not be\nwhat you want to do in the first place, and I happen to agree with\nthem (and that is why I am not very much interested in this topic).\n"},{"id":"222291","messageId":"CABURp0oQ9MNGZecD4mkniXMEUJ5L7Xn+JFQMEgc97Mfe26JYvg@mail.gmail.com","threadId":"34295","inReplyTo":"51D12A0E.60709@atlas-elektronik.com","subject":"Re: git clone -b","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-07-01T17:49:37Z","receivedAt":"2013-07-01T17:49:37Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"It would be nice to support more generic specs for the --branch\nswitch. But it is complicated because the refs have not been fetched\nyet during the clone, and so normal refs operations -- which expect to\nwork on a local repository -- do not work.  So, the ref is looked up\nlocally from a list in expected locations after fetching the remote\nrefs but before the clone occurs.  The remote refs which are fetched\nis not configurable during clone, and so only 'refs/heads/*' is\nfetched for non-mirrors.\n\nI was able to tweak git-clone to fetch the remote ref when I hacked\nbuiltin/clone.c to check in 'refs' and also to extend the refspec to\nsomething more broad (\"+refs/*:refs/remotes/origin/*\"), but this is\nnot a workable solution.  But there probably is a more correct way\nthan the hack I tried.\n\nPhil\n"},{"id":"222343","messageId":"51D274AA.2050902@atlas-elektronik.com","threadId":"34295","inReplyTo":"7v61wui5xe.fsf@alter.siamese.dyndns.org","subject":"Re: git clone -b","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2013-07-02T06:35:22Z","receivedAt":"2013-07-02T06:35:22Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 01.07.2013 18:46, schrieb Junio C Hamano:\n> Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:\n> \n>>> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)\n>>> or a tag (from refs/tags/) ?\n> \n> Because they are common enough, and doing the same for an arbitrary\n> object is just as easy to do something like:\n> \n> \tgit clone -n\n>         git checkout $an_arbitrary_commit_object_name^0\n\nOK. I wasn't aware of '-n' for 'git clone'. Thanks.\n\n> \n>>> Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/)\n>>> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)\n>>> and the 'build master' who wants to build that ref. \n> \n> While I wasn't paying much attention to this, I vaguely recall that\n> people pointed out that using a fresh clone every time may not be\n> what you want to do in the first place, and I happen to agree with\n> them (and that is why I am not very much interested in this topic).\n \nAs I said: We'd be using 'git archive --remote...' if that was\nsubmodule-aware.\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: Circular Definition: see Definition, Circular.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\"\n"},{"id":"222386","messageId":"7vppv0960p.fsf@alter.siamese.dyndns.org","threadId":"34295","inReplyTo":"51D274AA.2050902@atlas-elektronik.com","subject":"Re: git clone -b","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-02T18:21:58Z","receivedAt":"2013-07-02T18:21:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:\n\n>> While I wasn't paying much attention to this, I vaguely recall that\n>> people pointed out that using a fresh clone every time may not be\n>> what you want to do in the first place, and I happen to agree with\n>> them (and that is why I am not very much interested in this topic).\n>  \n> As I said: We'd be using 'git archive --remote...' if that was\n> submodule-aware.\n\nThat would still have to transfer full material enough to populate\nthe working tree for a single revision.  I was wondering why \"clone\nonce, and then update incrementally with 'fetch && reset --hard' &&\nclean'\" is not used, if the tree is for a build-bot.\n"},{"id":"222453","messageId":"20130703100118.GA21130@sigill.intra.peff.net","threadId":"34295","inReplyTo":"CABURp0oQ9MNGZecD4mkniXMEUJ5L7Xn+JFQMEgc97Mfe26JYvg@mail.gmail.com","subject":"Re: git clone -b","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-07-03T10:01:19Z","receivedAt":"2013-07-03T10:01:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 01, 2013 at 01:49:37PM -0400, Phil Hord wrote:\n\n> It would be nice to support more generic specs for the --branch\n> switch. But it is complicated because the refs have not been fetched\n> yet during the clone, and so normal refs operations -- which expect to\n> work on a local repository -- do not work.  So, the ref is looked up\n> locally from a list in expected locations after fetching the remote\n> refs but before the clone occurs.  The remote refs which are fetched\n> is not configurable during clone, and so only 'refs/heads/*' is\n> fetched for non-mirrors.\n\nI think there are two problems:\n\n  1. Our find_remote_branch function implements only half of the regular\n     ref_rev_parse_rules (heads and tags). Fixing that to make \"-b\n     refs/heads/master\" work is pretty easy. Patch is below.\n\n  2. When we give a ref that is not going to be fetched, we should\n     fetch it explicitly. It looks like --single-branch tries to do\n     this, but only handles tags. I am not sure what a non-single-branch\n     would want to do (since you are effectively overriding the\n     default refspecs).\n\n     So even with the patch, doing \"clone -b refs/foo/bar\" does not\n     quite work.\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 14b1323..5984303 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -433,24 +433,24 @@ static struct ref *find_remote_branch(const struct ref *refs, const char *branch\n \traise(signo);\n }\n \n-static struct ref *find_remote_branch(const struct ref *refs, const char *branch)\n+static struct ref *find_remote_branch(const struct ref *refs, const char *name)\n {\n-\tstruct ref *ref;\n-\tstruct strbuf head = STRBUF_INIT;\n-\tstrbuf_addstr(&head, \"refs/heads/\");\n-\tstrbuf_addstr(&head, branch);\n-\tref = find_ref_by_name(refs, head.buf);\n-\tstrbuf_release(&head);\n-\n-\tif (ref)\n-\t\treturn ref;\n-\n-\tstrbuf_addstr(&head, \"refs/tags/\");\n-\tstrbuf_addstr(&head, branch);\n-\tref = find_ref_by_name(refs, head.buf);\n-\tstrbuf_release(&head);\n-\n-\treturn ref;\n+\tint len = strlen(name);\n+\tconst char **p;\n+\n+\tfor (p = ref_rev_parse_rules; *p; p++) {\n+\t\tstruct ref *ref;\n+\n+\t\tref = find_ref_by_name(refs, mkpath(*p, len, name));\n+\t\tif (ref)\n+\t\t\t/*\n+\t\t\t * optionally check for and complain about ambiguity\n+\t\t\t * here, like dwim_ref does\n+\t\t\t */\n+\t\t\treturn ref;\n+\t}\n+\n+\treturn NULL;\n }\n \n static struct ref *wanted_peer_refs(const struct ref *refs,\n"}]}