{"thread":{"id":"47774","subject":"BUG: fetch in certain repo always gives \"did not send all necessary objects\"","startedAt":"2018-02-06T23:04:58Z","lastAt":"2018-02-07T18:17:12Z","messageCount":10,"participants":["Elijah Newren","Stefan Beller","Duy Nguyen","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"338544","messageId":"CABPp-BHVD19ZoAmWhQd9aN-v+qB7Ryq9Z-wobLYtJf_b6RWgzQ@mail.gmail.com","threadId":"47774","inReplyTo":null,"subject":"BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-02-06T23:04:51Z","receivedAt":"2018-02-06T23:04:58Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"[I cannot share the local repo and had to modify output of commands\nslightly to redact hostnames, branch names, etc. I think I haven't\nmessed anything up, but it's possible...]\n\nTwo people in the last week have come to me after running into a case\nwhere they could not update their repo because any call to git fetch\nor git pull would error out with\n\n fatal: bad object HEAD\n error: gerrit.server:reponame did not send all necessary objects\"\n\nwhich apparently has been reported before at both of:\n\nhttps://public-inbox.org/git/CAE5ih78nLL6UhKPObvFEA9xQZUtc1XpPvGJNaYTH9fJ0RyFRvA@mail.gmail.com/\nand\n\nhttps://public-inbox.org/git/CAGZ79kYP0z1G_H3nwfmSHraWHMBOcik5LepUXKj0nveeBrihiw@mail.gmail.com/\n\nbut without a resolution and it appears to have been difficult to\nreproduce. I can reproduce reliably with a copy of one of their\nrepos, and have dug in a little bit and may be able to provide more\ninfo. The pieces I've found that look relevant:\n\n* Both users were using git-2.16.1 (suggesting they update and try new\nthings often)\n* \"git fsck --no-dangling\" reports no problem on either client or server.\n* The error bisects to commit d0c39a49cc (\"revision.c: --all adds HEAD\nfrom all worktrees\", 2017-08-23).\n* The developer has 3 directories in use corresponding to different\nworktrees, but four entries under .git/worktrees, one of which appears\nthat it was once in use but no longer is\n* The unused entry under .git/worktrees has a detached HEAD that\npoints to an object that doesn't exist; I suspect it was garbage\ncollected.\n\nMore details about the last two items:\n\n$ ls ..\nmaster/ 1.0-release/ 2.0-release/ 3.0-release/\n\n$ for i in ../*/.git; do echo $i $(cat $i/.git 2>&1); done\n../master/.git cat: ../master/.git: Is a directory\n../1.0-release/.git gitdir: /clone/master/.git/worktrees/1.0-release\n../2.0-release/.git gitdir: /clone/master/.git/worktrees/2.0-release\n../3.0-release/.git gitdir: /clone/master/.git/worktrees/3.0-release1\n\n$ for i in .git/worktrees/*/gitdir; do echo $i $(cat $i); done\n.git/worktrees/1.0-release/gitdir /clone/1.0-release/.git\n.git/worktrees/2.0-release/gitdir /clone/2.0-release/.git\n.git/worktrees/3.0-release1/gitdir /clone/3.0-release/.git\n.git/worktrees/3.0-release/gitdir /clone/3.0-release/.git\n\n$ (cd .git && for i in worktrees/*/HEAD; do echo $i $(git rev-parse\n$i^{object}); done)\nworktrees/1.0-release/HEAD c483c6806fe19c2fa9bcda892e0ddb470f8e9d65\nworktrees/2.0-release/HEAD ab4c699ec9d1eab143c7e8ef51a0a6c451fcd4ea\nworktrees/3.0-release1/HEAD 55e52e24b24b2f81484de9c6ea7d4520238c5fd5\nfatal: ambiguous argument 'worktrees/3.0-release/HEAD^{object}':\nunknown revision or path not in the working tree.\nUse '--' to separate paths from revisions, like this:\n'git [...] -- [...]'\nworktrees/3.0-release/HEAD worktrees/3.0-release/HEAD^{object}\n\n\nSo, it appears both worktrees/3.0-release and worktrees/3.0-release1\nbelieve they are used by /clone/3.0-release/, but /clone/3.0-release\nuses worktree-3.0-release1. That leaves worktrees/3.0-release unused,\nand in fact its HEAD is some sha1 that does not exist in the repo --\npossibly GC'ed.\n\n\nAlso, after the investigation above and based on the hint in one of\nthe other email threads linked above, we tried 'git worktree prune'\nbut it didn't remove the unused directory under .git/worktree (perhaps\nbecause it thought something was using it?). The fetch bug didn't go\naway until doing an 'rm -rf .git/worktree/3.0-release'.\n\nI have no experience prior to today with git worktree, and the\ndeveloper in question doesn't remember how things got to the current\nstate. It was all a while ago.\n\n\nDoes anyone have an idea what may have happened here or how to avoid it?\n"},{"id":"338547","messageId":"CAGZ79kYstN9ATPGKZjnk-hJ6jRsx9Oz0b2hQ5cTiqVqMNDCsyA@mail.gmail.com","threadId":"47774","inReplyTo":"CABPp-BHVD19ZoAmWhQd9aN-v+qB7Ryq9Z-wobLYtJf_b6RWgzQ@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-02-06T23:20:58Z","receivedAt":"2018-02-06T23:21:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 6, 2018 at 3:04 PM, Elijah Newren wrote:\n\n>\n> Does anyone have an idea what may have happened here or how to avoid it?\n\nAccording to Peff this got fixed\nhttps://public-inbox.org/git/20171020031630.44zvzh3d2vlhglv4@sigill.intra.peff.net/\nand but you've had a corrupted repo from back when you were using an older\nversion of Git.\n\nDid that repo exist before d0c39a49cc was rolled out? Then we can keep that\nhypothesis of \"left-over corruption\" as Peff put it.\n"},{"id":"338549","messageId":"CABPp-BHkLLrJDTQwHTYpqC0Cg7Wv_wDr14Fq_LXneg+OzzRngg@mail.gmail.com","threadId":"47774","inReplyTo":"CAGZ79kYstN9ATPGKZjnk-hJ6jRsx9Oz0b2hQ5cTiqVqMNDCsyA@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-02-07T00:00:32Z","receivedAt":"2018-02-07T00:00:38Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Feb 6, 2018 at 3:20 PM, Stefan Beller wrote:\n> On Tue, Feb 6, 2018 at 3:04 PM, Elijah Newren wrote:\n>\n>>\n>> Does anyone have an idea what may have happened here or how to avoid it?\n>\n> According to Peff this got fixed\n> https://public-inbox.org/git/20171020031630.44zvzh3d2vlhglv4@sigill.intra.peff.net/\n> and but you've had a corrupted repo from back when you were using an older\n> version of Git.\n>\n> Did that repo exist before d0c39a49cc was rolled out? Then we can keep that\n> hypothesis of \"left-over corruption\" as Peff put it.\n\nI'm somewhat confused by this explanation. That precise commit is the\none I bisected to that _caused_ the fetch to fail. Also, there might\nbe one important difference here -- in the link you provide, it\nsuggests that you had a corrupted working directory that made use of a\nnow gc'ed commit. In the case I was able to dig into, we did not.\n(There was a left-over .git/worktree/ that had a now gc'ed\ncommit, but no working directory that used it.)\n\nI suspect you mean that there was another previous bug that induced\ncorruption, that this commit fixed that other bug, while also\nintroducing this new bug that makes folks' clones unusable because the\nerror doesn't provide enough information for users to know how to fix.\nIt took me hours to figure it out, after users ran out of ideas and\ncame and asked me for help. (Maybe if I was familiar with worktree,\nand knew they had been using it, then I might have guessed that \"HEAD\"\nmeant \"not your actual HEAD but the HEAD of the vestige of some other\nworktree\").\n\nDoes anyone have pointers about what might be doable in terms of\nproviding a more useful error message to allow users to recover?\nAnd/or ideas of what steps could cause corruption so I can send out a\nPSA to help users avoid it?\n\nIf not, I'll try to dig more, but I thought I'd ask others familiar\nwith this area.\n"},{"id":"338605","messageId":"CACsJy8CUgmyw6Ug6wQEFaj9Ze45mZfRoE4J16zVv5usT791Kmw@mail.gmail.com","threadId":"47774","inReplyTo":"CABPp-BHkLLrJDTQwHTYpqC0Cg7Wv_wDr14Fq_LXneg+OzzRngg@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-02-07T11:08:40Z","receivedAt":"2018-02-07T11:09:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 7, 2018 at 7:00 AM, Elijah Newren wrote:\n> and knew they had been using it, then I might have guessed that \"HEAD\"\n> meant \"not your actual HEAD but the HEAD of the vestige of some other\n> worktree\").\n>\n> Does anyone have pointers about what might be doable in terms of\n> providing a more useful error message to allow users to recover?\n\nI noticed this too. I was working on improving this message a bit but\ngot side tracked and since I figured this did not happen often\nanymore, this fix got lower priority than others. I'll resume that\nwork.\n\n> And/or ideas of what steps could cause corruption so I can send out a\n> PSA to help users avoid it?\n\nThere is another thing we could do. One bad HEAD should not abort the\nentire operation (at least if it's not the current worktree's HEAD).\nWe could still give a warning and move on, or don't warn at all and\nlet \"git worktree prune\" collect it (which I see from your message\nthat it also fails to do).\n\nI guess that's two more items on my todo list :) Sorry for all the\ntrouble because of this bug of mine.\n\n> If not, I'll try to dig more, but I thought I'd ask others familiar\n> with this area.\n-- \nDuy\n"},{"id":"338618","messageId":"20180207132157.GB16018@sigill.intra.peff.net","threadId":"47774","inReplyTo":"CABPp-BHkLLrJDTQwHTYpqC0Cg7Wv_wDr14Fq_LXneg+OzzRngg@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-07T13:21:57Z","receivedAt":"2018-02-07T13:22:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 06, 2018 at 04:00:32PM -0800, Elijah Newren wrote:\n\n> > According to Peff this got fixed\n> > https://public-inbox.org/git/20171020031630.44zvzh3d2vlhglv4@sigill.intra.peff.net/\n> > and but you've had a corrupted repo from back when you were using an older\n> > version of Git.\n> >\n> > Did that repo exist before d0c39a49cc was rolled out? Then we can keep that\n> > hypothesis of \"left-over corruption\" as Peff put it.\n> \n> I'm somewhat confused by this explanation. That precise commit is the\n> one I bisected to that _caused_ the fetch to fail. Also, there might\n> be one important difference here -- in the link you provide, it\n> suggests that you had a corrupted working directory that made use of a\n> now gc'ed commit. In the case I was able to dig into, we did not.\n> (There was a left-over .git/worktree/ that had a now gc'ed\n> commit, but no working directory that used it.)\n\nIf you had a corrupted .git/worktree//HEAD, then that does\nsound like the same problem. It's true that the commit you bisected to\ncaused \"fetch\" to fail, but only because it started looking at more of\nyour corrupted repository. The corruption happened long before (and I\ndon't know exactly when it was fixed, but I couldn't replicate it\nanymore; it might even still exist).\n\nIn your case it sounds like you have the extra twist that the matching\nworking directory for \"\" had gone away, but I don't think\nthat materially changes anything. Until you run \"git worktree prune\",\nthat HEAD file is still there and still supposed to be valid.\n\n> I suspect you mean that there was another previous bug that induced\n> corruption, that this commit fixed that other bug, while also\n> introducing this new bug that makes folks' clones unusable because the\n> error doesn't provide enough information for users to know how to fix.\n\nIf you want to call that last thing a bug, then I guess so. It's perhaps\na matter for the philosophers whether it is the fault of the new code to\nstart complaining about an existing on-disk corruption.\n\n> It took me hours to figure it out, after users ran out of ideas and\n> came and asked me for help. (Maybe if I was familiar with worktree,\n> and knew they had been using it, then I might have guessed that \"HEAD\"\n> meant \"not your actual HEAD but the HEAD of the vestige of some other\n> worktree\").\n\nYeah, this is the obvious thing that seems like it ought to be improved.\n\n> Does anyone have pointers about what might be doable in terms of\n> providing a more useful error message to allow users to recover?\n> And/or ideas of what steps could cause corruption so I can send out a\n> PSA to help users avoid it?\n\nHere's a minimal manual reproduction:\n\n # new repo...\n git init\n git commit --allow-empty -m one\n\n # with a worktree...\n git worktree add foo\n git -C foo commit --allow-empty -m two\n obj=.git/objects/$(git rev-parse foo | sed 's#..#&/#')\n\n # now we stop using that worktree\n git -C foo checkout --detach\n git branch -f -D foo\n rm -rf foo\n\n # and this is the corruption; this might have happened ye olden days\n # because of a bug in the worktree code, but we'll assume that somehow\n # the object went away\n rm -f $obj\n\nAnd now lots of commands may fail with confusing errors:\n\n $ git prune\n fatal: unable to parse object: HEAD\n\nUnfortunately fixing that is a little tricky. In this case the stack\nlooks like:\n\n parse_object_or_die (oid=0x7fffffffd690, name=0x555555792880 \"HEAD\") at object.c:239\n add_one_ref (path=0x555555792880 \"HEAD\", oid=0x7fffffffd690, flag=0, cb_data=0x7fffffffd8e0) at reachable.c:38\n refs_head_ref (refs=0x555555a65430, fn=0x5555556b6ef5 , cb_data=0x7fffffffd8e0) at refs.c:1316\n other_head_refs (fn=0x5555556b6ef5 , cb_data=0x7fffffffd8e0) at worktree.c:404\n\nSo other_head_refs knows that it's looking at the worktrees. And it\npasses the alternate ref-store to refs_head_ref(), with \"add_one_ref\" as\nthe callback. But the knowledge that we're not talking about the real\n\"HEAD\" is lost as we cross that callback boundary. We'd need to either\nadd another parameter to the callback, or have some way of talking about\n\"HEAD in this worktree\" as a refname (which AFAIK we don't have).\n\nAs for PSAs, my normal go-to in confusing matters like this is git-fsck.\nBut it seems that it does not check worktree HEADs. :(\n\n $ git fsck\n Checking object directories: 100% (256/256), done.\n\nSo that seems like another bug.\n\nThe best PSA for this particular bug may be \"try pruning the worktrees\":\n\n $ git worktree prune -v\n Removing worktrees/foo: gitdir file points to non-existent location\n\n $ git prune; echo $?\n 0\n\n-Peff\n"},{"id":"338619","messageId":"20180207132304.GC16018@sigill.intra.peff.net","threadId":"47774","inReplyTo":"CACsJy8CUgmyw6Ug6wQEFaj9Ze45mZfRoE4J16zVv5usT791Kmw@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-07T13:23:05Z","receivedAt":"2018-02-07T13:23:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 07, 2018 at 06:08:40PM +0700, Duy Nguyen wrote:\n\n> > And/or ideas of what steps could cause corruption so I can send out a\n> > PSA to help users avoid it?\n> \n> There is another thing we could do. One bad HEAD should not abort the\n> entire operation (at least if it's not the current worktree's HEAD).\n> We could still give a warning and move on, or don't warn at all and\n> let \"git worktree prune\" collect it (which I see from your message\n> that it also fails to do).\n\nWhether that's safe or not depends very much on what the caller intends\nto do with the ref. Skipping broken refs in \"git prune\" is a bad idea,\nfor instance.\n\n-Peff\n"},{"id":"338620","messageId":"20180207132511.GA19396@sigill.intra.peff.net","threadId":"47774","inReplyTo":"20180207132157.GB16018@sigill.intra.peff.net","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-07T13:25:11Z","receivedAt":"2018-02-07T13:25:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 07, 2018 at 08:21:57AM -0500, Jeff King wrote:\n\n> The best PSA for this particular bug may be \"try pruning the worktrees\":\n> \n> $ git worktree prune -v\n> Removing worktrees/foo: gitdir file points to non-existent location\n> \n> $ git prune; echo $?\n> 0\n\nSorry, I just read Stefan's response and not your original before\nresponding. I see that you did try that. So IMHO that's a separate bug\nthat \"worktree prune\" did not do the right thing for your particular\ncase.\n\n-Peff\n"},{"id":"338637","messageId":"CABPp-BH0rSELVJV11MJM=KFU2jAEuhVTzUUBskghgku+y_ozDQ@mail.gmail.com","threadId":"47774","inReplyTo":"20180207132157.GB16018@sigill.intra.peff.net","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-02-07T17:25:42Z","receivedAt":"2018-02-07T17:25:47Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Feb 7, 2018 at 5:21 AM, Jeff King wrote:\n> On Tue, Feb 06, 2018 at 04:00:32PM -0800, Elijah Newren wrote:\n>\n>> It took me hours to figure it out, after users ran out of ideas and\n>> came and asked me for help. (Maybe if I was familiar with worktree,\n>> and knew they had been using it, then I might have guessed that \"HEAD\"\n>> meant \"not your actual HEAD but the HEAD of the vestige of some other\n>> worktree\").\n>\n> Yeah, this is the obvious thing that seems like it ought to be improved.\n\n> Unfortunately fixing that is a little tricky. In this case the stack\n> looks like:\n>\n> parse_object_or_die (oid=0x7fffffffd690, name=0x555555792880 \"HEAD\") at object.c:239\n> add_one_ref (path=0x555555792880 \"HEAD\", oid=0x7fffffffd690, flag=0, cb_data=0x7fffffffd8e0) at reachable.c:38\n> refs_head_ref (refs=0x555555a65430, fn=0x5555556b6ef5 , cb_data=0x7fffffffd8e0) at refs.c:1316\n> other_head_refs (fn=0x5555556b6ef5 , cb_data=0x7fffffffd8e0) at worktree.c:404\n>\n> So other_head_refs knows that it's looking at the worktrees. And it\n> passes the alternate ref-store to refs_head_ref(), with \"add_one_ref\" as\n> the callback. But the knowledge that we're not talking about the real\n> \"HEAD\" is lost as we cross that callback boundary. We'd need to either\n> add another parameter to the callback, or have some way of talking about\n> \"HEAD in this worktree\" as a refname (which AFAIK we don't have).\n\nCan we use \"worktrees/${WORKTREE}/HEAD\"? It already satisfies all the\nnecessary rev-parse rules...\n\n(And on a slight tangent...do we want to start disallowing the\ncreation of branches/tags whose name starts with \"worktrees/\",\n\"refs/\", \"hooks/\", or other paths that exists under gitdir? Making a\nbranch named \"refs/heads/foo\" so that it fully-qualifies as\n\"refs/heads/refs/heads/foo\" is always fun)\n"},{"id":"338646","messageId":"CABPp-BGuTGf1A_WW_znsKKLD-2xDf+7-X1HxdvXx27oCXx8puA@mail.gmail.com","threadId":"47774","inReplyTo":"CACsJy8CUgmyw6Ug6wQEFaj9Ze45mZfRoE4J16zVv5usT791Kmw@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-02-07T18:12:59Z","receivedAt":"2018-02-07T18:13:05Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Feb 7, 2018 at 3:08 AM, Duy Nguyen wrote:\n> On Wed, Feb 7, 2018 at 7:00 AM, Elijah Newren wrote:\n>> and knew they had been using it, then I might have guessed that \"HEAD\"\n>> meant \"not your actual HEAD but the HEAD of the vestige of some other\n>> worktree\").\n>>\n>> Does anyone have pointers about what might be doable in terms of\n>> providing a more useful error message to allow users to recover?\n>\n> I noticed this too. I was working on improving this message a bit but\n> got side tracked and since I figured this did not happen often\n> anymore, this fix got lower priority than others. I'll resume that\n> work.\n\nSweet, that'd be great. Let me know if I can help.\n\n>> And/or ideas of what steps could cause corruption so I can send out a\n>> PSA to help users avoid it?\n>\n> There is another thing we could do. One bad HEAD should not abort the\n> entire operation (at least if it's not the current worktree's HEAD).\n> We could still give a warning and move on, or don't warn at all and\n> let \"git worktree prune\" collect it (which I see from your message\n> that it also fails to do).\n>\n> I guess that's two more items on my todo list :)\n\nCool, if you're taking a look at those, I'll take a look at the other\none mentioned by Peff in this thread -- \"make fsck pay attention to\nother worktree HEADs\" :-)\n\n> Sorry for all the trouble because of this bug of mine.\n\nLet me apologize if my tone came across too harshly in the report; I\nsometimes accidentally do that. Anyway, bugs happen. People were\nable to get back up and running with \"just reclone somewhere else\"\npretty quickly, and no one lost any important data here, it was just\njarring or perplexing enough that I felt the need to dig and figure\nout an improvement before more reports come in.\n\nBesides, you've made git a lot better. Thanks for that.\n"},{"id":"338647","messageId":"20180207181706.GA4227@sigill.intra.peff.net","threadId":"47774","inReplyTo":"CABPp-BH0rSELVJV11MJM=KFU2jAEuhVTzUUBskghgku+y_ozDQ@mail.gmail.com","subject":"Re: BUG: fetch in certain repo always gives \"did not send all necessary objects\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-07T18:17:06Z","receivedAt":"2018-02-07T18:17:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 07, 2018 at 09:25:42AM -0800, Elijah Newren wrote:\n\n> > So other_head_refs knows that it's looking at the worktrees. And it\n> > passes the alternate ref-store to refs_head_ref(), with \"add_one_ref\" as\n> > the callback. But the knowledge that we're not talking about the real\n> > \"HEAD\" is lost as we cross that callback boundary. We'd need to either\n> > add another parameter to the callback, or have some way of talking about\n> > \"HEAD in this worktree\" as a refname (which AFAIK we don't have).\n> \n> Can we use \"worktrees/${WORKTREE}/HEAD\"? It already satisfies all the\n> necessary rev-parse rules...\n\nTrue, but it's mostly an accident that it works. And once we have ref\nbackends besides the filesystem, it will probably stop working.\n\nI think there was discussion at some point of embedding worktree refs\ninto the normal ref namespace, but I don't know what came of it (it's\nnot a feature I've followed very closely).\n\n> (And on a slight tangent...do we want to start disallowing the\n> creation of branches/tags whose name starts with \"worktrees/\",\n> \"refs/\", \"hooks/\", or other paths that exists under gitdir? Making a\n> branch named \"refs/heads/foo\" so that it fully-qualifies as\n> \"refs/heads/refs/heads/foo\" is always fun)\n\nWe recently taught the porcelain to disallow a branch named \"HEAD\".\nThough I think there are actually two related problems with different\nsolutions. One is saying something like:\n\n git checkout -b HEAD\n\nor:\n\n git checkout -b refs/heads/foo\n\nboth of which will not do what you want, and leave you with a\nfunnily-named branch in the ref namespace.\n\nBut that's separate from the fact that:\n\n git rev-parse info/refs\n\nwill look at a file that is not a ref at all. Long-term I think the\nsolution is storage formats that don't mingle with other files. But we\ncould probably teach even the files-backend that any ref at the\ntop-level is supposed to be either in refs/, or to consist only of\n\"[A-Z_]\".\n\n-Peff\n"}]}