{"thread":{"id":"55490","subject":"`git fetch` not updating 'origin/HEAD' after branch rename","startedAt":"2021-04-13T20:25:50Z","lastAt":"2021-04-15T09:28:42Z","messageCount":10,"participants":["Sam Bostock","Junio C Hamano","Andreas Schwab","Chris Torek","Jeff King","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"421927","messageId":"CAHwnEogvmTZ-VS5GksoGEiyo3EHO+At+xeWa3frXUESD3HicnQ@mail.gmail.com","threadId":"55490","inReplyTo":null,"subject":"`git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Sam Bostock","fromEmail":"sam.bostock@shopify.com","sentAt":"2021-04-13T20:25:32Z","receivedAt":"2021-04-13T20:25:50Z","isPatch":false,"sender":{"key":"sam.bostock@shopify.com","avatar":"https://avatars.githubusercontent.com/u/8219340?v=4"},"body":"Hi!\n\nHopefully I followed the instructions on https://git-scm.com/community\ncorrectly to report this bug.\n\nLong story short, it seems to me that `git fetch` should update\n\"refs/remotes/origin/HEAD\" when the upstream HEAD changes, but it\ndoesn't. See my filled out bug report below.\n\nThanks,\n\nSam\n\n----\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n1. Clone a repo with some branch name (say \"master\") from some remote\norigin (say GitHub).\n2. Replace/rename the main branch on the remote (say \"main\").\n3. Run `git fetch` locally to sync with remote.\n4. Run `git rev-parse --abbrev-ref --verify origin/HEAD`.\n\nWhat did you expect to happen? (Expected behavior)\n\nThe `git fetch` should update the refs accordingly so \"origin/HEAD\"\nnow points to\nthe new branch, which should be output from the command above:\n\n $ git rev-parse --abbrev-ref --verify origin/HEAD\n origin/main\n\nWhat happened instead? (Actual behavior)\n\nThe \"origin/HEAD\" ref seems to not point to anything anymore (because the\nbranch it was pointing to was \"deleted\"). `git fetch` fails to update\nit to reflect the change.\n\n $ git rev-parse --abbrev-ref --verify origin/HEAD\n fatal: Needed a single revision\n\nWhat's different between what you expected and what actually happened?\n\nThe HEAD on origin has changed, but this change is not reflected in\nthe local refs by `git fetch`.\n\nAnything else you want to add:\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.30.2\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /nix/store/74shlfgb18717ixjlpivpxd7iqcyhyn5-bash-4.4-p23/bin/bash\nuname: Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05\nPST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64\ncompiler info: clang: 7.1.0 (tags/RELEASE_710/final)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /usr/local/bin/bash\n\n\n[Enabled Hooks]\n"},{"id":"421928","messageId":"xmqqlf9lly3d.fsf@gitster.g","threadId":"55490","inReplyTo":"CAHwnEogvmTZ-VS5GksoGEiyo3EHO+At+xeWa3frXUESD3HicnQ@mail.gmail.com","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-13T20:37:58Z","receivedAt":"2021-04-13T20:38:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Bostock writes:\n\n> Hopefully I followed the instructions on https://git-scm.com/community\n> correctly to report this bug.\n>\n> Long story short, it seems to me that `git fetch` should update\n> \"refs/remotes/origin/HEAD\" when the upstream HEAD changes, but it\n> doesn't. See my filled out bug report below.\n\nThat is working as intended.\n\nSince its inception, refs/remotes/origin/HEAD has been designed to\nmean \"the branch, which the owner of the repository considers the\nmost interesting for his/her purpose to keep track in the 'origin'\nremote repository\". It is perfectly OK to repoint origin/HEAD to\npoint at another branch you are interested in after you make a\nclone.\n\nThe origin/HEAD happens to be primed by noticing what the remote\nrepository sets HEAD to point to their branch upon cloning, but that\nis purely for convenience (i.e. HEAD branch of a repository offered\nfor cloning points at a branch the owner of the repository being\ncloned considers the primary branch in his/her repository, and that\noften coincides with the earlier definition of origin/HEAD for those\nwho clone such a repository). It would be a bug to update it to\nsomething other than you set (either passively by keeping what\n\"clone\" gave you initially, or actively by updating it to point at\nanother branch) upon \"git fetch\" from the remote.\n\nThere was an idea floated to use the same mechanism used by \"git\nclone\" to prime origin/HEAD upon \"git fetch\" when origin/HEAD is\nmissing, and I do not think there were many objections against the\nidea, so that may happen sometime in the future. It may also be\npossible to add \"git fetch --reset-remote-tracking-HEAD\" option to\nmake \"fetch\" overwrite existing origin/HEAD but somebody has to\npropose such a change, argue for its benefit and get it accepted by\nthe community.\n\nThanks.\n\n\n\n"},{"id":"421933","messageId":"87pmyxc2n3.fsf@igel.home","threadId":"55490","inReplyTo":"xmqqlf9lly3d.fsf@gitster.g","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2021-04-13T21:09:52Z","receivedAt":"2021-04-13T21:10:02Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Apr 13 2021, Junio C Hamano wrote:\n\n> It may also be\n> possible to add \"git fetch --reset-remote-tracking-HEAD\" option to\n> make \"fetch\" overwrite existing origin/HEAD but somebody has to\n> propose such a change, argue for its benefit and get it accepted by\n> the community.\n\nIsn't that what git remote set-head origin -a does?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"421934","messageId":"xmqqzgy1khgb.fsf@gitster.g","threadId":"55490","inReplyTo":"87pmyxc2n3.fsf@igel.home","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-13T21:22:44Z","receivedAt":"2021-04-13T21:22:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> On Apr 13 2021, Junio C Hamano wrote:\n>\n>> It may also be\n>> possible to add \"git fetch --reset-remote-tracking-HEAD\" option to\n>> make \"fetch\" overwrite existing origin/HEAD but somebody has to\n>> propose such a change, argue for its benefit and get it accepted by\n>> the community.\n>\n> Isn't that what git remote set-head origin -a does?\n\nYes, but the point is to do so when fetch is run (i.e. it talks with\nthe other side not just to learn which branch their HEAD points at,\nbut it actually does the fetching of new history on branches). And\nit might open the door to add a configuration to tell \"fetch\" to do\nso unconditionally, if it turns out to be useful enough.\n"},{"id":"421941","messageId":"CAPx1GvdeNEyPEZ7GdRKeAevnvjyLmoXHjQP0W6iToDsJPAqDHA@mail.gmail.com","threadId":"55490","inReplyTo":"CAHwnEogvmTZ-VS5GksoGEiyo3EHO+At+xeWa3frXUESD3HicnQ@mail.gmail.com","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2021-04-14T00:26:02Z","receivedAt":"2021-04-14T00:26:26Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Tue, Apr 13, 2021 at 5:18 PM Sam Bostock wrote:\n> Long story short, it seems to me that `git fetch` should update\n> \"refs/remotes/origin/HEAD\" when the upstream HEAD changes, but it\n> doesn't.\n\nIt's never been the *intent* to have `git fetch` update\nthe corresponding remote-tracking `HEAD` ref. To make\nthat happen, you must run `git remote`:\n\n git remote set-head origin -a\n\nfor instance.\n\nI have, however, often thought that this is the wrong\n*default* way for things to work, and that at least by default,\n`git fetch origin` should update `origin/HEAD` if the\nfetch result indicates that it should. See also Junio's\nreply. I think a configuration knob (similar to `fetch.prune`)\nwould be reasonable here. Users could then be encouraged\nto set `fetch.prune` to `true`, and `fetch.update-remote-HEAD`\n(or whatever) to `true` as well.\n\nChris\n"},{"id":"421947","messageId":"YHZ9w6MVMMHMxGeA@coredump.intra.peff.net","threadId":"55490","inReplyTo":"CAPx1GvdeNEyPEZ7GdRKeAevnvjyLmoXHjQP0W6iToDsJPAqDHA@mail.gmail.com","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-04-14T05:29:39Z","receivedAt":"2021-04-14T05:29:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 13, 2021 at 05:26:02PM -0700, Chris Torek wrote:\n\n> On Tue, Apr 13, 2021 at 5:18 PM Sam Bostock wrote:\n> > Long story short, it seems to me that `git fetch` should update\n> > \"refs/remotes/origin/HEAD\" when the upstream HEAD changes, but it\n> > doesn't.\n> \n> It's never been the *intent* to have `git fetch` update\n> the corresponding remote-tracking `HEAD` ref. To make\n> that happen, you must run `git remote`:\n> \n> git remote set-head origin -a\n> \n> for instance.\n> \n> I have, however, often thought that this is the wrong\n> *default* way for things to work, and that at least by default,\n> `git fetch origin` should update `origin/HEAD` if the\n> fetch result indicates that it should. See also Junio's\n> reply. I think a configuration knob (similar to `fetch.prune`)\n> would be reasonable here. Users could then be encouraged\n> to set `fetch.prune` to `true`, and `fetch.update-remote-HEAD`\n> (or whatever) to `true` as well.\n\nI think so, too. The previous discussion Junio referred to it is here:\n\n https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/\n\nIf you do read it, note that the parts of the conversation about unborn\nheads are out of date. We do pick this up via clone these days, courtesy\nof the commits in 69571dfe21 (Merge branch 'jt/clone-unborn-head',\n2021-02-17).\n\n-Peff\n"},{"id":"421963","messageId":"87sg3t16ec.fsf@evledraar.gmail.com","threadId":"55490","inReplyTo":"CAPx1GvdeNEyPEZ7GdRKeAevnvjyLmoXHjQP0W6iToDsJPAqDHA@mail.gmail.com","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-04-14T10:56:27Z","receivedAt":"2021-04-14T10:56:36Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Apr 14 2021, Chris Torek wrote:\n\n> On Tue, Apr 13, 2021 at 5:18 PM Sam Bostock wrote:\n>> Long story short, it seems to me that `git fetch` should update\n>> \"refs/remotes/origin/HEAD\" when the upstream HEAD changes, but it\n>> doesn't.\n>\n> It's never been the *intent* to have `git fetch` update\n> the corresponding remote-tracking `HEAD` ref. To make\n> that happen, you must run `git remote`:\n>\n> git remote set-head origin -a\n>\n> for instance.\n>\n> I have, however, often thought that this is the wrong\n> *default* way for things to work, and that at least by default,\n> `git fetch origin` should update `origin/HEAD` if the\n> fetch result indicates that it should. See also Junio's\n> reply. I think a configuration knob (similar to `fetch.prune`)\n> would be reasonable here. Users could then be encouraged\n> to set `fetch.prune` to `true`, and `fetch.update-remote-HEAD`\n> (or whatever) to `true` as well.\n\nAs you'll see from the previous linked thread I happen to agree with\nyou, but let's not step past that agreement and (no doubt subtly and\nunintentionally, in this case) misrepresent the other side, which also\nhas a legitimate argument.\n\nWhich is that this notion that \"[a client should update its view of a\nremote to what a] fetch result indicates that it should\" isn't something\nthat exists, and that we ever had it is only an emergent implementation\ndetail.\n\nSo first of all, a \"fetch result\" doesn't look anything like\nthat. Rather the server presents refs it has, and the client decides\nwhat it wants.\n\nWhich is the start of the disconnect in mental models around this. What\nyou see with \"git ls-remote origin\" != what you should expect to have at\na local refs/remotes/origin/* after a fetch.\n\nNothing in git itself actually needs this remote HEAD past clone time,\nand with 4f37d457065 (clone: respect remote unborn HEAD, 2021-02-05)\nthere'll be even less reason to pay attention to it.\n\nWe don't even always get it on \"clone\", we don't do it with \"--bare\",\nsince the reason we do it is to one-time setup the default branch, which\nwe then hardcode in the config in the non-bare case:\n\n [remote \"origin\"]\n url = https://github.com/git/git.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n [branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nSo arguably the bug is the other way around, that we should never save\nthis information at all in the ref store at \"clone\" time, which would\nmake \"init && config && fetch\" and \"clone\" consistent.\n\nI haven't looked, but wouldn't be surprised to discover that this was\noriginally needed back when we needed to ferry information between\nshellscripts, and was just diligently retained when the relevant parts\nwere rewritten in C.\n\nBut I digress.\n\nNow, what people *do actually* legitimately use this information is a\nconvenient local cache of \"what's the main upstream branch?\".\n\nI myself have written local scripts that used that, and been bitten by\nthis information being stale / not there (in the case of\ninit/config/fetch).\n\nBut why does anyone need that? Well, I don't think they actually\ndo. What they actually do want is to push or fetch the \"main\"\nbranch. The \"what was HEAD that one time I talked to this remote\" is\njust a roundabout way of getting that.\n\nSo isn't this whole thing just wart that we should fix in the protocol?\nWouldn't the use-case for this be satisfied with something like:\n\n [branch \"master\"]\n remote = origin\n merge = HEAD ; does not work as you might expect\n\nRight now that will just push to refs/heads/HEAD, but what if we had a\nprotocol extension to intercept it (or rather, some merge = , as an aside setting it\nto \":HEAD\" has some very funny results) wouldn't that satisfy the\nuse-case?\n\nAfter all, who's really interested in what the remote's idea of their\nHEAD when they last fetched is?\n\nDon't those users actually want the *current* idea of what HEAD is for\nthe purposes of fetching or pushing?\n\nIf we supported \"I want the tip of your HEAD\" (which we do) or \"I have\nthis ref update for you, on top of your idea of HEAD\" (we don't) you\ncould \"git push\" and it would do the right thing whether the primary\nbranch was renamed from \"master\" to \"main\" during your \"git push\" or\nnot.\n"},{"id":"421967","messageId":"87pmyxjcnz.fsf@igel.home","threadId":"55490","inReplyTo":"87sg3t16ec.fsf@evledraar.gmail.com","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2021-04-14T12:03:44Z","receivedAt":"2021-04-14T12:03:58Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Apr 14 2021, Ævar Arnfjörð Bjarmason wrote:\n\n> Nothing in git itself actually needs this remote HEAD past clone time,\n> and with 4f37d457065 (clone: respect remote unborn HEAD, 2021-02-05)\n> there'll be even less reason to pay attention to it.\n\nIsn't that what git rev-parse origin resolves to?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"421985","messageId":"xmqqim4oy3hi.fsf@gitster.g","threadId":"55490","inReplyTo":"87pmyxjcnz.fsf@igel.home","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T21:12:57Z","receivedAt":"2021-04-14T21:13:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> On Apr 14 2021, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Nothing in git itself actually needs this remote HEAD past clone time,\n>> and with 4f37d457065 (clone: respect remote unborn HEAD, 2021-02-05)\n>> there'll be even less reason to pay attention to it.\n>\n> Isn't that what git rev-parse origin resolves to?\n\nCorrect.\n\nAnd that is why refs/remotes/origin/HEAD is defined to point at the\nbranch that the owner of LOCAL repository considers is of interest,\nwhich may not be the same as what the owner of the REMOTE repository\nthinks is the primary branch in their worldview.\n\n\n"},{"id":"422016","messageId":"YHgHRpNDecY/d5UF@coredump.intra.peff.net","threadId":"55490","inReplyTo":"87sg3t16ec.fsf@evledraar.gmail.com","subject":"Re: `git fetch` not updating 'origin/HEAD' after branch rename","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-04-15T09:28:38Z","receivedAt":"2021-04-15T09:28:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 14, 2021 at 12:56:27PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Now, what people *do actually* legitimately use this information is a\n> convenient local cache of \"what's the main upstream branch?\".\n> \n> I myself have written local scripts that used that, and been bitten by\n> this information being stale / not there (in the case of\n> init/config/fetch).\n> \n> But why does anyone need that? Well, I don't think they actually\n> do. What they actually do want is to push or fetch the \"main\"\n> branch. The \"what was HEAD that one time I talked to this remote\" is\n> just a roundabout way of getting that.\n> \n> So isn't this whole thing just wart that we should fix in the protocol?\n> Wouldn't the use-case for this be satisfied with something like:\n> \n> [branch \"master\"]\n> remote = origin\n> merge = HEAD ; does not work as you might expect\n> \n> Right now that will just push to refs/heads/HEAD, but what if we had a\n> protocol extension to intercept it (or rather, some merge = incompatible with a current push, maybe \"$HEAD\">, as an aside setting it\n> to \":HEAD\" has some very funny results) wouldn't that satisfy the\n> use-case?\n\nKeep in mind that if we do not have a cache, then finding out the remote\nHEAD involves a network trip. But we use branch.*.merge in lots of\nplaces that aren't fetch/push. E.g., how would \"git rev-parse\n@{upstream}\" work with the config you gave above?\n\n> After all, who's really interested in what the remote's idea of their\n> HEAD when they last fetched is?\n> \n> Don't those users actually want the *current* idea of what HEAD is for\n> the purposes of fetching or pushing?\n\nIMHO the cache of the remote HEAD in refs/remotes/origin/HEAD is the\nsame as the cache of the remote refs in refs/remotes/origin/*. We only\ntalk to the network during fetch/push operations, but it is convenient\nto have a local cache that names the things we saw there.\n\nAs others mentioned, \"git rev-parse origin\" is another local command\nthat works without touching the network.\n\nSo I find the local cache of the remote HEAD quite useful. I think the\nonly issue with it is that it is not kept up to date like the rest of\nthe branches in refs/remotes/origin/*. That was an intentional decision,\nbecause you may want to define your own view of what is considered the\ndefault for the remote.\n\nBut that is a much rarer case than people who do want to auto-update it\non fetch (and for many years nobody cared too much, because people\nrarely updated HEAD anyway; but these days there's quite a lot of\nrenaming going on). So it makes sense to at least provide a configurable\noption to allow updating it on each fetch.\n\n-Peff\n"}]}