{"thread":{"id":"48591","subject":"Is origin/HEAD only being created on clone a bug? #leftoverbits","startedAt":"2018-05-29T18:30:46Z","lastAt":"2018-06-01T06:51:26Z","messageCount":7,"participants":["Ævar Arnfjörð Bjarmason","Brandon Williams","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"348712","messageId":"87bmcyfh67.fsf@evledraar.gmail.com","threadId":"48591","inReplyTo":null,"subject":"Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-05-29T18:30:40Z","receivedAt":"2018-05-29T18:30:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Here's some more #leftoverbits where we have a clone/fetch feature\ndiscrepancy and where clone is magical in ways that \"fetch\" isn't.\n\nIf you make an initial commit and push to a remote repo \"origin\", you\ndon't get a remote origin/HEAD reference, and a \"fetch\" won't create it\neither.\n\nYou will get it if you subseuqently \"clone\" the repo, but not if you use\n\"git init / remote add / fetch / git checkout -t\" which should otherwise\nbe equivalent.\n\nIf you push to \"master\" (or whatever HEAD is) from the clone the\norigin/HEAD will be updated accordingly, but from the repo you pushed\nfrom & the one you did init+fetch instead of clone you'll never see it.\n\nSome code spelunking reveals remote_head_points_at, guess_remote_head()\netc. in builtin/clone.c. I.e. this is special-cased as part of the\n\"clone\".\n\nCan anyone thing of a reason for why this shouldn't be fixed as a bug?\nI've tried searching the archives but \"origin/HEAD\" comes up with too\nmany\nresults. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t\nseems to be the patch that initially added it, but it is not discussed\nwhy this should be a clone-only special case that doesn't apply to\n\"fetch\".\n"},{"id":"348716","messageId":"20180529191725.GA259827@google.com","threadId":"48591","inReplyTo":"87bmcyfh67.fsf@evledraar.gmail.com","subject":"Re: Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2018-05-29T19:17:25Z","receivedAt":"2018-05-29T19:17:31Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 05/29, Ævar Arnfjörð Bjarmason wrote:\n> Here's some more #leftoverbits where we have a clone/fetch feature\n> discrepancy and where clone is magical in ways that \"fetch\" isn't.\n> \n> If you make an initial commit and push to a remote repo \"origin\", you\n> don't get a remote origin/HEAD reference, and a \"fetch\" won't create it\n> either.\n> \n> You will get it if you subseuqently \"clone\" the repo, but not if you use\n> \"git init / remote add / fetch / git checkout -t\" which should otherwise\n> be equivalent.\n> \n> If you push to \"master\" (or whatever HEAD is) from the clone the\n> origin/HEAD will be updated accordingly, but from the repo you pushed\n> from & the one you did init+fetch instead of clone you'll never see it.\n> \n> Some code spelunking reveals remote_head_points_at, guess_remote_head()\n> etc. in builtin/clone.c. I.e. this is special-cased as part of the\n> \"clone\".\n> \n> Can anyone thing of a reason for why this shouldn't be fixed as a bug?\n> I've tried searching the archives but \"origin/HEAD\" comes up with too\n> many\n> results. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t\n> seems to be the patch that initially added it, but it is not discussed\n> why this should be a clone-only special case that doesn't apply to\n> \"fetch\".\n\nI believe the issue has to deal with how symrefs are handled.  I don't\nthink any of the fetch code path does anything special with symrefs.\nSymref info does get sent over the wire for the HEAD symref but i think\nits just ignored.  You'll see updates for origin/HEAD when you\nsubsequently fetch most likely because its recorded as a symref locally\nwhich points at origin/master. This means that when you fetch\norigin/master, origin/HEAD will also but updated just because its\nlocally a pointer to origin/master.\n\nWith that said, yes we should probably fix this issue with fetch because\nI added symref support to protocol v2 so now symref information for refs\nother than HEAD can be sent across the wire but the client just throws\nthat info away at the moment.\n\n-- \nBrandon Williams\n"},{"id":"348770","messageId":"xmqqo9gyey13.fsf@gitster-ct.c.googlers.com","threadId":"48591","inReplyTo":"87bmcyfh67.fsf@evledraar.gmail.com","subject":"Re: Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-05-30T01:24:08Z","receivedAt":"2018-05-30T01:24:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> If you make an initial commit and push to a remote repo \"origin\", you\n> don't get a remote origin/HEAD reference, and a \"fetch\" won't create it\n> either.\n> ...\n> Some code spelunking reveals remote_head_points_at, guess_remote_head()\n> etc. in builtin/clone.c. I.e. this is special-cased as part of the\n> \"clone\".\n\nCorrect.  Originally, there was *no* way in the protocol to carry\nthe information, so the code always had to guess.  The point of\nsetting origin/HEAD was mostly so that you can say \"log origin..\"\nand rely on it getting dwimmed down to \"refs/remotes/%s/HEAD..\",\nand it wasn't a common practice to interact with multiple remotes\nwith remote tracking branches (integrator interacting with dozens\nof remotes, responding to pull requests using explicit URL but\nwithout configured remotes was not uncommon), so it was sufficient\nfor \"git clone\" to create it, and \"git remote add\" did not exist\nback then anyway.\n\nThere are two aspects in my answer to your question.\n\n - If we create additional remote (that is, other than the one we\n   get when we create a repository via \"clone\", so if your \"origin\"\n   is from \"git init there && cd there && git remote add origin\", it\n   does count in this category), should we get a remote-tracking\n   symref $name/HEAD so that we can say \"log $name..\"?  \n\n   We absolutely should.  We (eh, rather, those who added \"remote\n   add\"; this was not my itch and I am using \"royal we\" in this\n   sentence) just did not bother to and I think it is a bug that you\n   cannot say \"log $name..\"  Of course, it is just a \"git symbolic-ref\"\n   away to make it possible locally, so it is understandable if\n   \"remote add\" did not bother to.\n\n - When we fetch from a remote that has refs/remotes/$name/HEAD, and\n   if the protocol notices that their HEAD today is pointing to a\n   branch different from what our side has, should we repoint ours\n   to match?  \n\n   I am leaning against doing this, but mostly out of superstition.\n   Namely, I feel uneasy about the fact that the meaning of \"log\n   ..origin\" changes across a fetch in this sequence:\n\n     log ..origin && fetch origin && log ..origin\n\n   Without repointing origin/HEAD, two occurrences of \"log ..origin\"\n   both means \"how much ahead the primary branch we have been\n   interested in from this remote is, relative to our effort?\".\n   Even though we fully expect that two \"log ..origin\" would report\n   different results (after all, that is the whole point of doing\n   another one after \"fetch\" in such a sequence like this example),\n   our question is about the same \"primary branch we have been\n   interested in\".  But once fetch starts messing with where\n   origin/HEAD points at, that would no longer be the case, which is\n   why I am against doing something magical like that.\n\n"},{"id":"348773","messageId":"xmqqbmcxg8sn.fsf@gitster-ct.c.googlers.com","threadId":"48591","inReplyTo":"xmqqo9gyey13.fsf@gitster-ct.c.googlers.com","subject":"Re: Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-05-30T02:46:16Z","receivedAt":"2018-05-30T02:46:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>  - When we fetch from a remote that has refs/remotes/$name/HEAD, and\n>    if the protocol notices that their HEAD today is pointing to a\n>    branch different from what our side has, should we repoint ours\n>    to match?  \n>\n>    I am leaning against doing this, but mostly out of superstition.\n> ...\n>    interested in\".  But once fetch starts messing with where\n>    origin/HEAD points at, that would no longer be the case, which is\n>    why I am against doing something magical like that.\n\nWell, I shouldn't say \"I am against\" on the last line; rather, \"I\nfeel uneasy\".\n"},{"id":"348884","messageId":"87bmcw9sqc.fsf@evledraar.gmail.com","threadId":"48591","inReplyTo":"xmqqo9gyey13.fsf@gitster-ct.c.googlers.com","subject":"Re: Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-05-31T07:42:03Z","receivedAt":"2018-05-31T07:42:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, May 30 2018, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> If you make an initial commit and push to a remote repo \"origin\", you\n>> don't get a remote origin/HEAD reference, and a \"fetch\" won't create it\n>> either.\n>> ...\n>> Some code spelunking reveals remote_head_points_at, guess_remote_head()\n>> etc. in builtin/clone.c. I.e. this is special-cased as part of the\n>> \"clone\".\n>\n> Correct.  Originally, there was *no* way in the protocol to carry\n> the information, so the code always had to guess.  The point of\n> setting origin/HEAD was mostly so that you can say \"log origin..\"\n> and rely on it getting dwimmed down to \"refs/remotes/%s/HEAD..\",\n> and it wasn't a common practice to interact with multiple remotes\n> with remote tracking branches (integrator interacting with dozens\n> of remotes, responding to pull requests using explicit URL but\n> without configured remotes was not uncommon), so it was sufficient\n> for \"git clone\" to create it, and \"git remote add\" did not exist\n> back then anyway.\n>\n> There are two aspects in my answer to your question.\n>\n>  - If we create additional remote (that is, other than the one we\n>    get when we create a repository via \"clone\", so if your \"origin\"\n>    is from \"git init there && cd there && git remote add origin\", it\n>    does count in this category), should we get a remote-tracking\n>    symref $name/HEAD so that we can say \"log $name..\"?\n>\n>    We absolutely should.  We (eh, rather, those who added \"remote\n>    add\"; this was not my itch and I am using \"royal we\" in this\n>    sentence) just did not bother to and I think it is a bug that you\n>    cannot say \"log $name..\"  Of course, it is just a \"git symbolic-ref\"\n>    away to make it possible locally, so it is understandable if\n>    \"remote add\" did not bother to.\n>\n>  - When we fetch from a remote that has refs/remotes/$name/HEAD, and\n>    if the protocol notices that their HEAD today is pointing to a\n>    branch different from what our side has, should we repoint ours\n>    to match?\n>\n>    I am leaning against doing this, but mostly out of superstition.\n>    Namely, I feel uneasy about the fact that the meaning of \"log\n>    ..origin\" changes across a fetch in this sequence:\n>\n>      log ..origin && fetch origin && log ..origin\n>\n>    Without repointing origin/HEAD, two occurrences of \"log ..origin\"\n>    both means \"how much ahead the primary branch we have been\n>    interested in from this remote is, relative to our effort?\".\n>    Even though we fully expect that two \"log ..origin\" would report\n>    different results (after all, that is the whole point of doing\n>    another one after \"fetch\" in such a sequence like this example),\n>    our question is about the same \"primary branch we have been\n>    interested in\".  But once fetch starts messing with where\n>    origin/HEAD points at, that would no longer be the case, which is\n>    why I am against doing something magical like that.\n\nWe already have to deal with this special case of origin/HEAD being\nre-pointed in a repository that we \"clone\", so we would just do whatever\nhappens to a repository that's cloned.\n\nI.e. the \"clone\" sets the origin/HEAD up as a one-off, and then keeps\nupdating it on the basis of updating existing refs. We'd similarly set\nit up as a one-off if we ever \"fetch\" and notice that the ref doesn't\nexist yet, and then we'd update it in the same way we update it now.\n\nSo this seems like a non-issue to me as far as me coming up with some\npatch to one-off write the origin/HEAD on the first \"fetch\", or am I\nmissing something?\n"},{"id":"348955","messageId":"xmqqd0xbb8bn.fsf@gitster-ct.c.googlers.com","threadId":"48591","inReplyTo":"87bmcw9sqc.fsf@evledraar.gmail.com","subject":"Re: Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-06-01T01:32:12Z","receivedAt":"2018-06-01T01:32:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> We already have to deal with this special case of origin/HEAD\n> being re-pointed in a repository that we \"clone\", so we would just\n> do whatever happens to a repository that's cloned.\n\nOK.  Not visiting that issue while we discuss this \"origin/HEAD is\nuseful, so create it even for non-initial-clone case\" topic makes it\nsimpler to discuss.\n"},{"id":"348978","messageId":"20180601065121.GA15578@sigill.intra.peff.net","threadId":"48591","inReplyTo":"xmqqbmcxg8sn.fsf@gitster-ct.c.googlers.com","subject":"Re: Is origin/HEAD only being created on clone a bug? #leftoverbits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-06-01T06:51:21Z","receivedAt":"2018-06-01T06:51:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> >  - When we fetch from a remote that has refs/remotes/$name/HEAD, and\n> >    if the protocol notices that their HEAD today is pointing to a\n> >    branch different from what our side has, should we repoint ours\n> >    to match?  \n> >\n> >    I am leaning against doing this, but mostly out of superstition.\n> > ...\n> >    interested in\".  But once fetch starts messing with where\n> >    origin/HEAD points at, that would no longer be the case, which is\n> >    why I am against doing something magical like that.\n> \n> Well, I shouldn't say \"I am against\" on the last line; rather, \"I\n> feel uneasy\".\n\nI didn't bother to dig up the past discussions, but I am pretty sure we\nintentionally avoided updating origin/HEAD without an explicit action\nfrom the user. Because what the other side considers \"the default\nbranch\" and what you consider \"the default branch\" when dealing with the\nremote are not necessarily the same thing. If we auto-adjust the symref\non fetch, we might be undoing the user's previous \"git remote set-head\"\noperation.\n\nI don't have any real problem with creating it if it _doesn't_ exist,\nthough. (I think ideally it would get created by \"remote add\", but that\ncommand does not always talk to the remote, so this kind of\ndelayed-create is probably the best we can do).\n\n-Peff\n"}]}