{"thread":{"id":"59341","subject":"How to mirror and augment a git repository","startedAt":"2023-03-04T12:19:25Z","lastAt":"2023-03-13T16:38:07Z","messageCount":10,"participants":["Sebastian Tennant","Bagas Sanjaya","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"473002","messageId":"87ilfgemkb.fsf@sebyte.me","threadId":"59341","inReplyTo":null,"subject":"How to mirror and augment a git repository","fromName":"Sebastian Tennant","fromEmail":"sdt@sebyte.me","sentAt":"2023-03-04T12:19:16Z","receivedAt":"2023-03-04T12:19:25Z","isPatch":false,"sender":{"key":"sdt@sebyte.me","avatar":null},"body":"Hello list,\n\nI wish to mirror _and augment_ an upstream git repository.\n\n              .--------.\n              |Upstream|\n              '--------'\n                   |\n          .----------------.\n          |Augmented mirror|\n          '----------------'\n           /       |       \\\n   .--------. .--------. .--------.\n   |Client#1| |Client#2| |Client#3|\n   '--------' '--------' '--------'\n\nClients of the augmented mirror must have access to everything\navailable from upstream but must also be able to collaborate on\nadditional development branches not available from upstream.\n\nInitial approach:\n\n Augmented mirror:\n\n   $ git clone --mirror <upstream> upstream\n   $ cd upstream\n   $ git remote update  # regular cron job\n\n Clients (bare repo & worktrees preferred):\n\n   $ git clone --bare <mirror> mirror\n   $ cd mirror\n   $ git config remote.origin.fetch\\\n         \"+refs/heads/*:refs/remotes/origin/*\"\n   $ git remote update\n\n\nThis arrangement worked fine until I decded to run:\n\n   $ git remote prune origin\n\non the augmented mirror and lost all the additional development\nbranches the clients had added and shared amongst themselves.\n\nI've tried running the augmented mirror as a plain bare repo, i.e.\n\n   $ git config --unset remote.origin.fetch\n   $ git config --unset remote.origin.mirror\n\nbut then the cron job (git remote update) is no longer sufficient in\nmaking all upstream activity available downstream.\n\nSo, how best to run an augmented mirror such as this?\n\nIf my initial approach was correct, is there a way to protect the\nadditional branches so that ‘git remote prune origin’ may be run\nsafely on the augmented mirror from time to time?\n\nAny help/tips/pointers/suggestions much appreciated.\n\nSebastian\n"},{"id":"473023","messageId":"143e4a36-02cc-d2a6-ff60-6b143d9e47b4@gmail.com","threadId":"59341","inReplyTo":"87ilfgemkb.fsf@sebyte.me","subject":"Re: How to mirror and augment a git repository","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2023-03-05T09:02:05Z","receivedAt":"2023-03-05T09:02:19Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 3/4/23 19:19, Sebastian Tennant wrote:\n> Hello list,\n> \n> I wish to mirror _and augment_ an upstream git repository.\n> \n>               .--------.\n>               |Upstream|\n>               '--------'\n>                    |\n>           .----------------.\n>           |Augmented mirror|\n>           '----------------'\n>            /       |       \\\n>    .--------. .--------. .--------.\n>    |Client#1| |Client#2| |Client#3|\n>    '--------' '--------' '--------'\n> \n> Clients of the augmented mirror must have access to everything\n> available from upstream but must also be able to collaborate on\n> additional development branches not available from upstream.\n> \n\nI guess the augmented mirror is integration tree before changes\nfrom clients going upstream, right?\n\n-- \nAn old man doll... just what I always wanted! - Clara\n\n"},{"id":"473025","messageId":"87mt4rcyt0.fsf@sebyte.me","threadId":"59341","inReplyTo":"143e4a36-02cc-d2a6-ff60-6b143d9e47b4@gmail.com","subject":"Re: How to mirror and augment a git repository","fromName":"Sebastian Tennant","fromEmail":"sdt@sebyte.me","sentAt":"2023-03-05T09:50:03Z","receivedAt":"2023-03-05T09:50:14Z","isPatch":false,"sender":{"key":"sdt@sebyte.me","avatar":null},"body":"Quoth Bagas Sanjaya <bagasdotme@gmail.com>\non Sun, 5 Mar 2023 16:02:05 +0700:\n> On 3/4/23 19:19, Sebastian Tennant wrote:\n>> Hello list,\n>> \n>> I wish to mirror _and augment_ an upstream git repository.\n>> \n>>               .--------.\n>>               |Upstream|\n>>               '--------'\n>>                    |\n>>           .----------------.\n>>           |Augmented mirror|\n>>           '----------------'\n>>            /       |       \\\n>>    .--------. .--------. .--------.\n>>    |Client#1| |Client#2| |Client#3|\n>>    '--------' '--------' '--------'\n>> \n>> Clients of the augmented mirror must have access to everything\n>> available from upstream but must also be able to collaborate on\n>> additional development branches not available from upstream.\n>> \n>\n> I guess the augmented mirror is integration tree before changes\n> from clients going upstream, right?\n\nSome of the changes introduced by the clients may end up being\naccepted upstream.  The augmented mirror is primarily a way of\ncollaborating on and distributing customisations between clients.\n"},{"id":"473041","messageId":"ZAWfkkmrPUqNmrtu@coredump.intra.peff.net","threadId":"59341","inReplyTo":"87ilfgemkb.fsf@sebyte.me","subject":"Re: How to mirror and augment a git repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-03-06T08:08:50Z","receivedAt":"2023-03-06T08:09:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 04, 2023 at 12:19:16PM +0000, Sebastian Tennant wrote:\n\n>  Augmented mirror:\n> \n>    $ git clone --mirror <upstream> upstream\n>    $ cd upstream\n>    $ git remote update  # regular cron job\n\nThe problem here is that your refspec for \"origin\" in the mirror will be\n\"+refs/*:refs/*\". So it claims to have responsibility for the whole refs\nnamespace. And because of the \"+\", it will happily overwrite local refs\nwhen fetching, including branches pushed up by the client. You noticed\nit most with \"prune\", because that deletes local branches not present in\nupstream repo. But a similar problem would happen if both a client and\nthe upstream had a branch named \"foo\".\n\n> I've tried running the augmented mirror as a plain bare repo, i.e.\n> \n>    $ git config --unset remote.origin.fetch\n>    $ git config --unset remote.origin.mirror\n> \n> but then the cron job (git remote update) is no longer sufficient in\n> making all upstream activity available downstream.\n\nRight. If you drop the fetch refspec entirely, then it will only fetch\nHEAD during your cron jobs, which is not what you want. You want a\nrefspec that tells Git to fetch everything, but you need to divide up\nthe \"refs/\" namespace into local stuff and mirrored stuff.\n\nYou could use the normal \"+refs/heads/*:refs/remotes/origin/*\" refspec,\nbut it's awkward for the clients to access \"refs/remotes/\" on the\nmirror.\n\nSo you probably want to keep the upstream branches in \"refs/heads/\", but\nmark a special part of the namespace. Like:\n\n  cd augmented-mirror\n  git config remote.origin.fetch '+refs/heads/*:refs/heads/upstream/*'\n\nAnd then \"git fetch\" will pull all of the remote branches into the\n\"upstream/\" namespace. And it's safe to prune, because it will only\ndelete branches in refs/heads/upstream/ (and you may want to just \"git\nfetch --prune\" as you fetch via cron, which is a little more efficient\nthan a separate \"git remote prune\").\n\nClients can name their branches whatever they like, as long as they\ndon't start with \"upstream/\", and that won't interfere with the mirror.\n\n-Peff\n"},{"id":"473201","messageId":"87fsaf9oa8.fsf@sebyte.me","threadId":"59341","inReplyTo":"ZAWfkkmrPUqNmrtu@coredump.intra.peff.net","subject":"Re: How to mirror and augment a git repository","fromName":"Sebastian Tennant","fromEmail":"sdt@sebyte.me","sentAt":"2023-03-08T16:54:39Z","receivedAt":"2023-03-08T16:56:57Z","isPatch":false,"sender":{"key":"sdt@sebyte.me","avatar":null},"body":"Hello Jeff,\n\nThanks for your explanation.  It's been really helpful.\n\nQuoth Jeff King <peff@peff.net>\non Mon, 6 Mar 2023 03:08:50 -0500:\n> On Sat, Mar 04, 2023 at 12:19:16PM +0000, Sebastian Tennant wrote:\n>\n>>  Augmented mirror:\n>>\n>>    $ git clone --mirror <upstream> upstream\n>>    $ cd upstream\n>>    $ git remote update  # regular cron job\n>\n> The problem here is that your refspec for \"origin\" in the mirror\n> will be \"+refs/*:refs/*\". So it claims to have responsibility for\n> the whole refs namespace. And because of the \"+\", it will happily\n> overwrite local refs when fetching, including branches pushed up by\n> the client. You noticed it most with \"prune\", because that deletes\n> local branches not present in upstream repo. But a similar problem\n> would happen if both a client and the upstream had a branch named\n> \"foo\".\n\nUnderstood.\n\n>> I've tried running the augmented mirror as a plain bare repo, i.e.\n>>\n>>    $ git config --unset remote.origin.fetch\n>>    $ git config --unset remote.origin.mirror\n>>\n>> but then the cron job (git remote update) is no longer sufficient in\n>> making all upstream activity available downstream.\n>\n> Right. If you drop the fetch refspec entirely, then it will only fetch\n> HEAD during your cron jobs, which is not what you want.\n\nPrecisely.\n\n> You want a refspec that tells Git to fetch everything, but you need\n> to divide up the \"refs/\" namespace into local stuff and mirrored\n> stuff.\n>\n> You could use the normal \"+refs/heads/*:refs/remotes/origin/*\" refspec,\n> but it's awkward for the clients to access \"refs/remotes/\" on the\n> mirror.\n\nIndeed.  To fetch a known ref, a client (also with the normal fetch\nrefspec) would have to do something like this, for example:\n\n $ git fetch origin\\\n       refs/remotes/origin/<ref>:refs/remotes/upstream/<ref>\n\nAlternatively, they could add an additional fetch refspec to their\nconfig:\n\n[remote=\"origin\"]\n ...\n fetch = +refs/heads/*:refs/remotes/origin/*             # normal\n fetch = +refs/remotes/origin/*:refs/remotes/upstream/*  # additional\n\nThis would have the advantage of fetching all the upstream refs on the\nnext update giving them a better idea of what's happening upstream.\n\nIs my understanding more or less correct?\n\n> So you probably want to keep the upstream branches in \"refs/heads/\",\n> but mark a special part of the namespace. Like:\n>\n>   cd augmented-mirror\n>   git config remote.origin.fetch '+refs/heads/*:refs/heads/upstream/*'\n>\n> And then \"git fetch\" will pull all of the remote branches into the\n> \"upstream/\" namespace.\n\nI see.  And creating the 'upstream' namespace under 'heads' (instead\nof under 'remotes') is crucial, since any client (with a normal fetch\nrefspec) will then receive those refs automatically, i.e. without the\nadditional fetch refspec I've described above.\n\n> And it's safe to prune, because it will only delete branches in\n> refs/heads/upstream/ (and you may want to just \"git fetch --prune\"\n> as you fetch via cron, which is a little more efficient than a\n> separate \"git remote prune\").\n\nUnderstood and noted.\n\n> Clients can name their branches whatever they like, as long as they\n> don't start with \"upstream/\", and that won't interfere with the\n> mirror.\n\nGot it.  Thanks again.\n\nSebastian\n"},{"id":"473250","messageId":"ZAlOnTovp0ncZopf@coredump.intra.peff.net","threadId":"59341","inReplyTo":"87fsaf9oa8.fsf@sebyte.me","subject":"Re: How to mirror and augment a git repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-03-09T03:12:29Z","receivedAt":"2023-03-09T03:12:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 08, 2023 at 04:54:39PM +0000, Sebastian Tennant wrote:\n\n> > You could use the normal \"+refs/heads/*:refs/remotes/origin/*\" refspec,\n> > but it's awkward for the clients to access \"refs/remotes/\" on the\n> > mirror.\n> \n> Indeed.  To fetch a known ref, a client (also with the normal fetch\n> refspec) would have to do something like this, for example:\n> \n>  $ git fetch origin\\\n>        refs/remotes/origin/<ref>:refs/remotes/upstream/<ref>\n> \n> Alternatively, they could add an additional fetch refspec to their\n> config:\n> \n> [remote=\"origin\"]\n>  ...\n>  fetch = +refs/heads/*:refs/remotes/origin/*             # normal\n>  fetch = +refs/remotes/origin/*:refs/remotes/upstream/*  # additional\n> \n> This would have the advantage of fetching all the upstream refs on the\n> next update giving them a better idea of what's happening upstream.\n> \n> Is my understanding more or less correct?\n\nYes, that's exactly correct. In some ways it is cleaner than using\n\"refs/heads/upstream\" because it leaves the whole \"refs/heads/\"\nnamespace intact for local client branches. It depends on how much of a\npain it is to configure the extra refspec in each client. :)\n\n-Peff\n"},{"id":"473403","messageId":"87o7oz7eer.fsf@sebyte.me","threadId":"59341","inReplyTo":"ZAlOnTovp0ncZopf@coredump.intra.peff.net","subject":"Re: How to mirror and augment a git repository","fromName":"Sebastian Tennant","fromEmail":"sdt@sebyte.me","sentAt":"2023-03-11T10:47:40Z","receivedAt":"2023-03-11T10:47:49Z","isPatch":false,"sender":{"key":"sdt@sebyte.me","avatar":null},"body":"Hello Jeff,\n\nAlas, I thought I understood fetch refspecs, but it appears not.\n\nQuoth Jeff King <peff@peff.net>\non Wed, 8 Mar 2023 22:12:29 -0500:\n> On Wed, Mar 08, 2023 at 04:54:39PM +0000, Sebastian Tennant wrote:\n> […]\n>> Indeed.  To fetch a known ref, a client (also with the normal fetch\n>> refspec) would have to do something like this, for example:\n>>\n>>  $ git fetch origin\\\n>>        refs/remotes/origin/<ref>:refs/remotes/upstream/<ref>\n>>\n>> Alternatively, they could add an additional fetch refspec to their\n>> config:\n>>\n>> [remote=\"origin\"]\n>>  ...\n>>  fetch = +refs/heads/*:refs/remotes/origin/*             # normal\n>>  fetch = +refs/remotes/origin/*:refs/remotes/upstream/*  # additional\n>>\n>> This would have the advantage of fetching all the upstream refs on\n>> the next update giving them a better idea of what's happening\n>> upstream.\n>>\n>> Is my understanding more or less correct?\n>\n> Yes, that's exactly correct. In some ways it is cleaner than using\n> \"refs/heads/upstream\" because it leaves the whole \"refs/heads/\"\n> namespace intact for local client branches. It depends on how much\n> of a pain it is to configure the extra refspec in each client. :)\n\nI decided to go with the cleaner approach.\n\nHere are the actions I'm taking to configure the mirror:\n\n $ git clone --bare https://url.of/project.git\n $ cd project.git\n $ git remote rename origin upstream\n $ git config remote.upstream.fetch\\\n       '+refs/heads/*:refs/remotes/upstream/*'\n $ git fetch upstream --prune\n\nAt this point there are no refs under refs/heads (and very many under\nrefs/remotes/upstream).\n\nHere are the actions I'm then taking on a client:\n\n $ git clone --bare mirror:path/to/project.git\n $ cd project.git\n $ git remote rename origin mirror\n $ git config remote.mirror.fetch\\\n       '+refs/heads/*:refs/remotes/mirror/*'\n\nAt this point, both mirror and client have a normal fetch refspec,\ni.e. no additional refspec has been added to the client, yet when I\nrun:\n\n $ git fetch mirror --prune\n\non the client, all the refs on mirror under refs/remotes/upstream are\nfetched and placed under refs/remotes/mirror on the client.\n\nMy understanding of refspec:\n\n +refs/heads/*:refs/remotes/mirror/*\n\nis \"fetch only those refs under refs/heads and place them under\nrefs/remotes/mirror\", which in this case should mean that no refs are\nfetched (since there are none on mirror under refs/heads).\n\nWhat's going on here that I'm just not getting?\n\nIf I add the additional refspec to the client:\n\n $ git config --add remote.mirror.fetch\\\n   '+refs/remotes/upstream/*:refs/remotes/upstream/*'\n\nand fetch once more, I end up with all the refs already under\nrefs/remotes/mirror duplicated under refs/remotes/upstream.\n\nSebastian\n"},{"id":"473404","messageId":"ZAyWUS27M+degQxj@coredump.intra.peff.net","threadId":"59341","inReplyTo":"87o7oz7eer.fsf@sebyte.me","subject":"Re: How to mirror and augment a git repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-03-11T14:55:13Z","receivedAt":"2023-03-11T14:55:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 11, 2023 at 10:47:40AM +0000, Sebastian Tennant wrote:\n\n> Here are the actions I'm taking to configure the mirror:\n> \n>  $ git clone --bare https://url.of/project.git\n>  $ cd project.git\n>  $ git remote rename origin upstream\n>  $ git config remote.upstream.fetch\\\n>        '+refs/heads/*:refs/remotes/upstream/*'\n>  $ git fetch upstream --prune\n> \n> At this point there are no refs under refs/heads (and very many under\n> refs/remotes/upstream).\n\nYou'd have refs under refs/heads at this point. They were created when\nyou did the original bare clone (since bare clones fetch all heads to\nstart with, though they don't set up a refspec).\n\nAnd they won't be deleted by the pruning fetch, of course, because you\nconfigured the refspec to limit itself to refs/remotes/upstream on the\nlocal side.\n\nIf you don't want them (and I think you don't), you can just initialize\nthe repository directly, and then fetch, like:\n\n  git init --bare project.git\n  cd project.git\n  git config remote.upstream.url https://url.of/project.git\n  [and then configure refspec and fetch --prune as before]\n\n> Here are the actions I'm then taking on a client:\n> \n>  $ git clone --bare mirror:path/to/project.git\n>  $ cd project.git\n>  $ git remote rename origin mirror\n>  $ git config remote.mirror.fetch\\\n>        '+refs/heads/*:refs/remotes/mirror/*'\n\nThis bare clone will do the same thing. So you'll end up with a copy of\nall of the heads created in the earlier step. Worse, they won't be the\ncurrent state of those branches, but stale ones left from when you\ncreated the mirror repo.\n\nI think you want _two_ refspecs in the clients:\n\n  - one to fetch the client-local branches stored on the mirror. That\n    is:\n\n      +refs/heads/*:refs/remotes/origin/*\n\n    and those branches just appear as normal.\n\n  - one to fetch the mirrored upstream branches from the special\n    namespace on the mirror. That one is:\n\n      +refs/remotes/upstream/*:refs/remotes/upstream/*\n\n> At this point, both mirror and client have a normal fetch refspec,\n> i.e. no additional refspec has been added to the client, yet when I\n> run:\n> \n>  $ git fetch mirror --prune\n> \n> on the client, all the refs on mirror under refs/remotes/upstream are\n> fetched and placed under refs/remotes/mirror on the client.\n\nThe refspec you showed above for the client is fetching from\nrefs/heads/* on the remote side. So it will never look at\nrefs/remotes/upstream from the mirror.\n\n> My understanding of refspec:\n> \n>  +refs/heads/*:refs/remotes/mirror/*\n> \n> is \"fetch only those refs under refs/heads and place them under\n> refs/remotes/mirror\", which in this case should mean that no refs are\n> fetched (since there are none on mirror under refs/heads).\n\nYour understanding is right, but the gotcha of how \"clone --bare\" works\nis making things more confusing.\n\n> What's going on here that I'm just not getting?\n> \n> If I add the additional refspec to the client:\n> \n>  $ git config --add remote.mirror.fetch\\\n>    '+refs/remotes/upstream/*:refs/remotes/upstream/*'\n> \n> and fetch once more, I end up with all the refs already under\n> refs/remotes/mirror duplicated under refs/remotes/upstream.\n\nRight. Those are the copies you actually _want_ to have. The ones pulled\nfrom refs/heads/* aren't. You'd expect that to be empty to start, and\nthen eventually it would be populated by pushes from local clients.\n\n-Peff\n"},{"id":"473417","messageId":"87pm9d6drp.fsf@sebyte.me","threadId":"59341","inReplyTo":"ZAyWUS27M+degQxj@coredump.intra.peff.net","subject":"Re: How to mirror and augment a git repository","fromName":"Sebastian Tennant","fromEmail":"sdt@sebyte.me","sentAt":"2023-03-12T18:11:22Z","receivedAt":"2023-03-12T18:20:21Z","isPatch":false,"sender":{"key":"sdt@sebyte.me","avatar":null},"body":"Quoth Jeff King <peff@peff.net>\non Sat, 11 Mar 2023 09:55:13 -0500:\n> On Sat, Mar 11, 2023 at 10:47:40AM +0000, Sebastian Tennant wrote:\n>\n>> Here are the actions I'm taking to configure the mirror:\n>>\n>>  $ git clone --bare https://url.of/project.git\n>>  $ cd project.git\n>>  $ git remote rename origin upstream\n>>  $ git config remote.upstream.fetch\\\n>>        '+refs/heads/*:refs/remotes/upstream/*'\n>>  $ git fetch upstream --prune\n>>\n>> At this point there are no refs under refs/heads (and very many under\n>> refs/remotes/upstream).\n>\n> You'd have refs under refs/heads at this point.  They were created\n> when you did the original bare clone (since bare clones fetch all\n> heads to start with, though they don't set up a refspec).\n\nI see the refs under refs/heads at last!\n\nMy mistake was looking for them in the file system (instead of in file\n‘packed-refs’).\n\n> And they won't be deleted by the pruning fetch, of course, because\n> you configured the refspec to limit itself to refs/remotes/upstream\n> on the local side.\n>\n> If you don't want them (and I think you don't), you can just initialize\n> the repository directly, and then fetch, like:\n>\n>   git init --bare project.git\n>   cd project.git\n>   git config remote.upstream.url https://url.of/project.git\n>   [and then configure refspec and fetch --prune as before]\n\nThis is precisely the behaviour I've been wanting (and mistakenly\nexpecting).\n\n>> Here are the actions I'm then taking on a client:\n>>\n>>  $ git clone --bare mirror:path/to/project.git\n>>  $ cd project.git\n>>  $ git remote rename origin mirror\n>>  $ git config remote.mirror.fetch\\\n>>        '+refs/heads/*:refs/remotes/mirror/*'\n>\n> This bare clone will do the same thing. So you'll end up with a copy\n> of all of the heads created in the earlier step. Worse, they won't\n> be the current state of those branches, but stale ones left from\n> when you created the mirror repo.\n>\n> I think you want _two_ refspecs in the clients:\n>\n>   - one to fetch the client-local branches stored on the mirror. That\n>     is:\n>\n>       +refs/heads/*:refs/remotes/origin/*\n>\n>     and those branches just appear as normal.\n>\n>   - one to fetch the mirrored upstream branches from the special\n>     namespace on the mirror. That one is:\n>\n>       +refs/remotes/upstream/*:refs/remotes/upstream/*\n\nYup, this is what I want, and actually what I already have in place,\nconfiguration wise.\n\nThe problem was in my partial understanding of the consequences of\npassing option --bare to ‘git clone’ (and in my not thinking to look\nin file ‘packed-refs’).\n\nThanks again Jeff.\n\nSebastian\n"},{"id":"473458","messageId":"ZA9Pr90hFpSQaaU/@coredump.intra.peff.net","threadId":"59341","inReplyTo":"87pm9d6drp.fsf@sebyte.me","subject":"Re: How to mirror and augment a git repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-03-13T16:30:39Z","receivedAt":"2023-03-13T16:38:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 12, 2023 at 06:11:22PM +0000, Sebastian Tennant wrote:\n\n> > You'd have refs under refs/heads at this point.  They were created\n> > when you did the original bare clone (since bare clones fetch all\n> > heads to start with, though they don't set up a refspec).\n> \n> I see the refs under refs/heads at last!\n> \n> My mistake was looking for them in the file system (instead of in file\n> ‘packed-refs’).\n\nThe best way to check is \"git for-each-ref\", which handles the storage\ndetails (including if we ever move to a new storage mechanism like\nreftable).\n\n> The problem was in my partial understanding of the consequences of\n> passing option --bare to ‘git clone’ (and in my not thinking to look\n> in file ‘packed-refs’).\n\nTo be fair, I usually have to double-check the rules for \"--bare\"\nmyself. :)\n\nGlad everything is working now.\n\n-Peff\n"}]}