{"thread":{"id":"64265","subject":"[BUG] git clone from bundle with --all does not fetch all refs","startedAt":"2025-10-07T21:11:51Z","lastAt":"2025-10-08T19:19:41Z","messageCount":7,"participants":["Andrew Harmon","Junio C Hamano","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"528167","messageId":"BL3PR13MB5209A87037FC19CBB9B2916EBBE0A@BL3PR13MB5209.namprd13.prod.outlook.com","threadId":"64265","inReplyTo":null,"subject":"[BUG] git clone from bundle with --all does not fetch all refs","fromName":"Andrew Harmon","fromEmail":"aharmon@signalquest.com","sentAt":"2025-10-07T21:11:43Z","receivedAt":"2025-10-07T21:11:51Z","isPatch":false,"sender":{"key":"aharmon@signalquest.com","avatar":null},"body":"# Problem with git bundle --all and git clone for air-gapped transfer to offline environments\n\n## Description\n\nWhen creating a bundle using `git bundle create --all`, all refs including `refs/remotes/origin/*` are included in the bundle. However, when cloning from this bundle using `git clone`, these remote refs are not automatically fetched, making many branches inaccessible.\n\n## Steps to Reproduce\n\n1. In a repository with multiple branches and remote tracking branches (e.g., after cloning from GitLab/GitHub)\n2. Create a bundle: `git bundle create repo.bundle --all`\n3. Verify bundle contents: `git bundle list-heads repo.bundle` (shows both `refs/heads/*` and `refs/remotes/origin/*`)\n4. Clone from bundle: `git clone repo.bundle cloned-repo`\n5. Check available branches: `cd cloned-repo && git branch -a`\n\n## Expected Behavior\n\nAll refs included in the bundle (both `refs/heads/*` and `refs/remotes/origin/*`) should be accessible after cloning. Users should be able to see and checkout all branches that were in the original repository.\n\n## Actual Behavior\n\nOnly refs under `refs/heads/*` in the bundle become remote tracking branches. Refs stored as `refs/remotes/origin/*` in the bundle are not fetched during clone, making these branches inaccessible without manual intervention.\n\n## Workaround\n\nAfter cloning, manually fetch the remote refs:\n\n```bash\ngit fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*'\n```\n\n## Impact\n\nThis breaks the expected workflow for distributing complete repository snapshots via bundles (e.g., for offline environments). Users expect `git bundle --all` followed by `git clone` to preserve all branches.\n\nThe `--all` flag documentation states it includes \"all refs\", but the cloning behavior does not match this expectation. This creates a surprising and unintuitive user experience when bundles are used for offline repository distribution.\n\n## Environment\n\n[System Info]\ngit version:\ngit version 2.45.2.windows.1\ncpu: x86_64\nbuilt from commit: 91d03cb2e4fbf6ad961ace739b8a646868cb154d\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Windows 10.0 26100 \ncompiler info: gnuc: 14.1\nlibc info: no libc information available\n$SHELL (typically, interactive shell): C:\\Program Files\\Git\\usr\\bin\\bash.exe\n\n## Suggested Fix\n\nOne of the following approaches could address this issue:\n\n1. **Automatic fetch during clone**: `git clone` should automatically fetch all refs present in a bundle, including `refs/remotes/origin/*`, OR\n\n2. **Bundle creation remapping**: `git bundle create --all` should convert `refs/remotes/origin/*` to `refs/heads/*` so they're properly restored during clone, OR\n\n3. **Documentation improvement**: Document this behavior clearly in `git-bundle` and `git-clone` documentation with the workaround, including a note that `--all` does not guarantee all refs will be available after cloning without additional steps.\n\n## Additional Context\n\nThis issue was discovered while preparing repository snapshots for developers working in offline/air-gapped environments. The workflow of `git bundle create --all` >> transfer >> `git clone` appears to be a complete solution but silently loses access to most branches.\n\n\n*********************************\nAndrew Harmon\naharmon@signalquest.com\n\nSignalQuest - precision microsensors\n10 Water Street, Lebanon, NH, 03766\n(603)-448-6266\n*********************************\n\n"},{"id":"528176","messageId":"xmqqa522icjy.fsf@gitster.g","threadId":"64265","inReplyTo":"BL3PR13MB5209A87037FC19CBB9B2916EBBE0A@BL3PR13MB5209.namprd13.prod.outlook.com","subject":"Re: [BUG] git clone from bundle with --all does not fetch all refs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-07T22:15:13Z","receivedAt":"2025-10-07T22:15:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Harmon <aharmon@signalquest.com> writes:\n\n> # Problem with git bundle --all and git clone for air-gapped\n> transfer to offline environments\n>\n> ## Description\n>\n> When creating a bundle using `git bundle create --all`, all refs\n> including `refs/remotes/origin/*` are included in the\n> bundle. However, when cloning from this bundle using `git clone`,\n> these remote refs are not automatically fetched, making many\n> branches inaccessible.\n>\n> ## Steps to Reproduce\n>\n> 1. In a repository with multiple branches and remote tracking branches (e.g., after cloning from GitLab/GitHub)\n> 2. Create a bundle: `git bundle create repo.bundle --all`\n> 3. Verify bundle contents: `git bundle list-heads repo.bundle` (shows both `refs/heads/*` and `refs/remotes/origin/*`)\n> 4. Clone from bundle: `git clone repo.bundle cloned-repo`\n> 5. Check available branches: `cd cloned-repo && git branch -a`\n\n> ## Expected Behavior\n>\n> All refs included in the bundle (both `refs/heads/*` and `refs/remotes/origin/*`) should be accessible after cloning. Users should be able to see and checkout all branches that were in the original repository.\n\nIf I am not misreading the scenario presented, then this expectation\nis wrong.\n\n> ## Actual Behavior\n>\n> Only refs under `refs/heads/*` in the bundle become remote tracking branches. Refs stored as `refs/remotes/origin/*` in the bundle are not fetched during clone, making these branches inaccessible without manual intervention.\n\nThis is totally expected.  Think of cloning from a bundle is just\nlike cloning from the original remote (limited to the refs included\nin the bundle, of course).  Local branches of the remote (i.e. the\nones that corresponds to refs/heads/* you saw in your bundle) become\nyour remote-tracking branches.  Their remote-tracking branches are\nnot even visible, unless you explicitly ask \"clone\" to.  Which means ...\n\n> ## Workaround\n>\n> After cloning, manually fetch the remote refs:\n>\n> ```bash\n> git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*'\n> ```\n\n... this is not even a workaround, but how you would ask for their\nremote-tracking branches.\n\nOr \n\n    $ git init && git fetch repo.bndl \"refs/*:refs/*\"\n\nwhich is like doing a mirror clone (\"git clone --mirror\").\n"},{"id":"528184","messageId":"BL3PR13MB520981A726145113DCA8B910BBE0A@BL3PR13MB5209.namprd13.prod.outlook.com","threadId":"64265","inReplyTo":"xmqqa522icjy.fsf@gitster.g","subject":"RE: [BUG] git clone from bundle with --all does not fetch all refs","fromName":"Andrew Harmon","fromEmail":"aharmon@signalquest.com","sentAt":"2025-10-07T23:11:16Z","receivedAt":"2025-10-07T23:11:24Z","isPatch":false,"sender":{"key":"aharmon@signalquest.com","avatar":null},"body":"Hi Junio,\n\nThanks for the reply. I'm a bit out of my depth but tried to write a good bug report.\n\nThe experience of \"cloning from bundle should be just like cloning from github\" did not happen for me. Maybe I created the bundle wrong?\n\nSee the workflow, below. Is the problem that refs are put in the bundle at refs/remotes/origin/* instead of refs/heads/*?\n\nuser@machine MINGW64 ~\n$ mkdir tmp\n\nuser@machine MINGW64 ~\n$ cd tmp\n\nuser@machine MINGW64 ~/tmp\n$ git clone git@GITLAB_HOST:external_sources/matrice_sq.git\nCloning into 'matrice_sq'...\nremote: Enumerating objects: 1512, done.\nremote: Counting objects: 100% (139/139), done.\nremote: Compressing objects: 100% (137/137), done.\nremote: Total 1512 (delta 79), reused 0 (delta 0), pack-reused 1373 (from 1)\nReceiving objects: 100% (1512/1512), 537.88 KiB | 4.68 MiB/s, done.\nResolving deltas: 100% (1070/1070), done.\n\nuser@machine MINGW64 ~/tmp\n$ cd matrice_sq\n\nuser@machine MINGW64 ~/tmp/matrice_sq (develop)\n$ git branch -r\n  origin/21-Add-benchmark-application\n  origin/51-inlining-config-matrix-base\n  origin/Add_readme\n  origin/DspCortexM4\n  origin/HEAD -> origin/develop\n  origin/develop\n  origin/master\n  origin/wip-develop-no-inline\n  origin/wip-expression-templates\n  origin/wip-inlining-config\n  origin/wip-kf-imu-gm-states\n  origin/wip-nested-submatrix-tests\n  origin/wip-sqinav-initial-version\n  origin/wip/matrix-base-public-operators\n  origin/wip_ins_resource_investigation\n\nuser@machine MINGW64 ~/tmp/matrice_sq (develop)\n$ git bundle create ../matrice_sq.bundle --all\nEnumerating objects: 1512, done.\nCounting objects: 100% (1512/1512), done.\nDelta compression using up to 16 threads\nCompressing objects: 100% (435/435), done.\nWriting objects: 100% (1512/1512), 537.83 KiB | 76.83 MiB/s, done.\nTotal 1512 (delta 1070), reused 1512 (delta 1070), pack-reused 0 (from 0)\n\nuser@machine MINGW64 ~/tmp/matrice_sq (develop)\n$ git bundle verify ../matrice_sq.bundle\nThe bundle contains these 18 refs:\n1b32e892e571c11c764e8d79e7970afe89378327 refs/heads/develop\n06881c8a501f166b41d71c8a7a025daa5bf768ea refs/remotes/origin/21-Add-benchmark-application\nb09e56be3d6ae35774544590c1dc8ae88b4d87f9 refs/remotes/origin/51-inlining-config-matrix-base\n093d3bff0316e7281ba0b094f7d79e3d16793b15 refs/remotes/origin/Add_readme\n241e5d6f6116f8bfae399c766c92d9b2013e61ab refs/remotes/origin/DspCortexM4\n1b32e892e571c11c764e8d79e7970afe89378327 refs/remotes/origin/HEAD\n1b32e892e571c11c764e8d79e7970afe89378327 refs/remotes/origin/develop\n0c6d1fce26af62c104a0c0297b693d9c0f164bdc refs/remotes/origin/master\ne9afacb6d77e888b29e9ece12863fb13bc8df3ad refs/remotes/origin/wip-develop-no-inline\n47004f08fc09bf97f9a12e81726edc05f7390409 refs/remotes/origin/wip-expression-templates\n8047b97041ce82d2e6b4e193332ddb1d8337fd84 refs/remotes/origin/wip-inlining-config\ned8238c5ab80ec3039a29c65dcec574fca6e7017 refs/remotes/origin/wip-kf-imu-gm-states\n4c20baac85dfce2077f9e997f2c5ea4f25392b46 refs/remotes/origin/wip-nested-submatrix-tests\ne909df72e6e52ece8b7fed9362578e1d4a89fb45 refs/remotes/origin/wip-sqinav-initial-version\n9a8ab3d9bcb4a2c2384d0c545634d45e0daf60ed refs/remotes/origin/wip/matrix-base-public-operators\n8720c64e04aeeef02f54a611665f9b0777e8572c refs/remotes/origin/wip_ins_resource_investigation\n0c6d1fce26af62c104a0c0297b693d9c0f164bdc refs/tags/Matrice-SQ-v1.0.0\n1b32e892e571c11c764e8d79e7970afe89378327 HEAD\nThe bundle records a complete history.\nThe bundle uses this hash algorithm: sha1\n../matrice_sq.bundle is okay\n\nuser@machine MINGW64 ~/tmp/matrice_sq (develop)\n$ cd ..\n\nuser@machine MINGW64 ~/tmp\n$ git clone matrice_sq.bundle matrice_copy\nCloning into 'matrice_copy'...\nReceiving objects: 100% (1512/1512), 537.83 KiB | 11.69 MiB/s, done.\nResolving deltas: 100% (1070/1070), done.\n\nuser@machine MINGW64 ~/tmp\n$ cd matrice_copy\n\nuser@machine MINGW64 ~/tmp/matrice_copy (develop)\n$ git branch -r\n  origin/HEAD -> origin/develop\n  origin/develop\n\n>>>>> At this point, I would expect to see everything from origin that I normally get when cloning from gitlab, but I don't.\n\n\n\n-----Original Message-----\nFrom: Junio C Hamano <gitster@pobox.com> \nSent: Tuesday, October 7, 2025 18:15\nTo: Andrew Harmon <aharmon@signalquest.com>\nCc: git@vger.kernel.org\nSubject: Re: [BUG] git clone from bundle with --all does not fetch all refs\n\nAndrew Harmon <aharmon@signalquest.com> writes:\n\n> # Problem with git bundle --all and git clone for air-gapped transfer \n> to offline environments\n>\n> ## Description\n>\n> When creating a bundle using `git bundle create --all`, all refs \n> including `refs/remotes/origin/*` are included in the bundle. However, \n> when cloning from this bundle using `git clone`, these remote refs are \n> not automatically fetched, making many branches inaccessible.\n>\n> ## Steps to Reproduce\n>\n> 1. In a repository with multiple branches and remote tracking branches \n> (e.g., after cloning from GitLab/GitHub) 2. Create a bundle: `git \n> bundle create repo.bundle --all` 3. Verify bundle contents: `git \n> bundle list-heads repo.bundle` (shows both `refs/heads/*` and \n> `refs/remotes/origin/*`) 4. Clone from bundle: `git clone repo.bundle \n> cloned-repo` 5. Check available branches: `cd cloned-repo && git \n> branch -a`\n\n> ## Expected Behavior\n>\n> All refs included in the bundle (both `refs/heads/*` and `refs/remotes/origin/*`) should be accessible after cloning. Users should be able to see and checkout all branches that were in the original repository.\n\nIf I am not misreading the scenario presented, then this expectation is wrong.\n\n> ## Actual Behavior\n>\n> Only refs under `refs/heads/*` in the bundle become remote tracking branches. Refs stored as `refs/remotes/origin/*` in the bundle are not fetched during clone, making these branches inaccessible without manual intervention.\n\nThis is totally expected.  Think of cloning from a bundle is just like cloning from the original remote (limited to the refs included in the bundle, of course).  Local branches of the remote (i.e. the ones that corresponds to refs/heads/* you saw in your bundle) become your remote-tracking branches.  Their remote-tracking branches are not even visible, unless you explicitly ask \"clone\" to.  Which means ...\n\n> ## Workaround\n>\n> After cloning, manually fetch the remote refs:\n>\n> ```bash\n> git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*'\n> ```\n\n... this is not even a workaround, but how you would ask for their remote-tracking branches.\n\nOr\n\n    $ git init && git fetch repo.bndl \"refs/*:refs/*\"\n\nwhich is like doing a mirror clone (\"git clone --mirror\").\n\n"},{"id":"528283","messageId":"xmqqo6qhfgtb.fsf@gitster.g","threadId":"64265","inReplyTo":"BL3PR13MB520981A726145113DCA8B910BBE0A@BL3PR13MB5209.namprd13.prod.outlook.com","subject":"Re: [BUG] git clone from bundle with --all does not fetch all refs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-08T17:23:44Z","receivedAt":"2025-10-08T17:23:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Harmon <aharmon@signalquest.com> writes:\n\n> The experience of \"cloning from bundle should be just like cloning\n> from github\" did not happen for me. Maybe I created the bundle\n> wrong?\n\nI did not say \"github\", though ;-)\n\n> See the workflow, below. Is the problem that refs are put in the\n> bundle at refs/remotes/origin/* instead of refs/heads/*?\n\nEverything looks as expected, including how you prepared a bundle\nfile.  Perhaps your expectation of what a bundle file is for is\ndifferent from what bundle files are designed for?  By that, I mean\nthat you may have a use case the designers of \"git bundle\" feature\nnever anticipated.\n\nThe primary and only use case \"git bundle\" was designed to cater to\nwas this.  The user has a repository on this machine that they want\nto be cloned to another machine, but for whatever reason, it cannot\nbe done over the network by typing \"git clone ...\" on that other\nmachine against this machine.  So the user makes a bundle out of the\nrepository on this machine, copy that file on a USB stick, bring it\nover there, and then the user says \"git clone ...\" against the\nbundle file as if they are cloning from the original.\n\nFor that to work, refs/heads/master in the original repository is\nstored as refs/heads/master in the bundle.  The remote-tracking\nbranches may by default not copied into the bundle, but you can by\ninstructing \"git bundle\" command.\n\nAnd if you want to copy the remote-tracking branches via \"git clone\"\nor \"git fetch\" over the network, you'd specifically ask for them,\nas \"clone\" would by default prepare fetch refspecs for their local \nbranches to be copied to your remote-tracking branches, and their\nrefs/tags/ copied to your refs/tags/. and nothing else.  As a bundle\nfile wants to imitate end-user experience of cloning or fetching\nover the network from the original repository for sneaker-net\noperation, the need for specifically asking is the same if you want\nto grab (their) remote-tracking branches out of a bundle file.\n\nStepping back a bit, how would you make a more-or-less exact copy\nof an existing repository over the network?  \"git clone --mirror\"\nis probably the mechanism where their refs/heads/master becomes the\nrefs/heads/master in the resulting repository and the remote-tracking\nbranches they have in their refs/remotes/origin/* would become the\nremote-tracking branches refs/remotes/origin/* in the resulting\nrepository.  So perhaps doing that against the bundle file would do\nwhat you wanted to do?  If that is the case, then perhaps your use\ncase was covered by the original design of the \"git bundle\" feature\nafter all---to allow you to clone or fetch from the file as if you\nare cloning or fetching from the original repository.\n\nHTH.\n"},{"id":"528286","messageId":"BN0PR13MB5216EC49DD37699C766B8DD6BBE1A@BN0PR13MB5216.namprd13.prod.outlook.com","threadId":"64265","inReplyTo":"xmqqo6qhfgtb.fsf@gitster.g","subject":"RE: [BUG] git clone from bundle with --all does not fetch all refs","fromName":"Andrew Harmon","fromEmail":"aharmon@signalquest.com","sentAt":"2025-10-08T18:17:14Z","receivedAt":"2025-10-08T18:17:16Z","isPatch":false,"sender":{"key":"aharmon@signalquest.com","avatar":null},"body":"> The primary and only use case \"git bundle\" was designed to cater to was this.\n> The user has a repository on this machine that they want to be cloned to\n> another machine, but for whatever reason, it cannot be done over the network\n> by typing \"git clone ...\" on that other machine against this machine.  So the\n> user makes a bundle out of the repository on this machine, copy that file on a\n> USB stick, bring it over there, and then the user says \"git clone ...\" against\n> the bundle file as if they are cloning from the original.\n\nThis is exactly my use case. I found that I also needed to do:\ngit fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*'\n\nAs an end user, I found this very surprising. I was expecting to call:\ngit clone <repo-bundle>\nand have this behave just like:\ngit clone <ssh-or-https-target>\n\nMaybe we are talking past each other? Following the documentation, I didn't think that anything beyond \"git clone <repo-bundle>\" was required to unpack the bundle.\n\n\nFILE: bundle-demo.sh\n\n#!/bin/bash\n\nset -e\n\n# cleanup from last run\nrm -rf matrice_sq*\n\necho \"\"\necho \"Clone the repo via SSH\"\ngit clone git@UBUBEAR:external_sources/matrice_sq.git matrice_sq\n\necho \"\"\necho \"View available remote branches\"\n(cd matrice_sq && git branch -r)\n\necho \"\"\necho \"Pack the bundle for offline distribution\"\n(cd matrice_sq && git bundle create ../matrice_sq.bundle --all)\n(cd matrice_sq && git bundle verify ../matrice_sq.bundle)\n\necho \"\"\necho \"Unpack the bundle on new machine\"\ngit clone matrice_sq.bundle matrice_sq.new\n(cd matrice_sq.new && git branch -r)\n\necho \"\"\necho \"Manually fetch refs from refs/remotes/origin/*\"\n(cd matrice_sq.new && git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*')\n(cd matrice_sq.new && git branch -r)\n\n\n\n-----Original Message-----\nFrom: Junio C Hamano <gitster@pobox.com> \nSent: Wednesday, October 8, 2025 13:24\nTo: Andrew Harmon <aharmon@signalquest.com>\nCc: git@vger.kernel.org\nSubject: Re: [BUG] git clone from bundle with --all does not fetch all refs\n\nAndrew Harmon <aharmon@signalquest.com> writes:\n\n> The experience of \"cloning from bundle should be just like cloning \n> from github\" did not happen for me. Maybe I created the bundle wrong?\n\nI did not say \"github\", though ;-)\n\n> See the workflow, below. Is the problem that refs are put in the \n> bundle at refs/remotes/origin/* instead of refs/heads/*?\n\nEverything looks as expected, including how you prepared a bundle file.  Perhaps your expectation of what a bundle file is for is different from what bundle files are designed for?  By that, I mean that you may have a use case the designers of \"git bundle\" feature never anticipated.\n\nThe primary and only use case \"git bundle\" was designed to cater to was this.  The user has a repository on this machine that they want to be cloned to another machine, but for whatever reason, it cannot be done over the network by typing \"git clone ...\" on that other machine against this machine.  So the user makes a bundle out of the repository on this machine, copy that file on a USB stick, bring it over there, and then the user says \"git clone ...\" against the bundle file as if they are cloning from the original.\n\nFor that to work, refs/heads/master in the original repository is stored as refs/heads/master in the bundle.  The remote-tracking branches may by default not copied into the bundle, but you can by instructing \"git bundle\" command.\n\nAnd if you want to copy the remote-tracking branches via \"git clone\"\nor \"git fetch\" over the network, you'd specifically ask for them, as \"clone\" would by default prepare fetch refspecs for their local branches to be copied to your remote-tracking branches, and their refs/tags/ copied to your refs/tags/. and nothing else.  As a bundle file wants to imitate end-user experience of cloning or fetching over the network from the original repository for sneaker-net operation, the need for specifically asking is the same if you want to grab (their) remote-tracking branches out of a bundle file.\n\nStepping back a bit, how would you make a more-or-less exact copy of an existing repository over the network?  \"git clone --mirror\"\nis probably the mechanism where their refs/heads/master becomes the refs/heads/master in the resulting repository and the remote-tracking branches they have in their refs/remotes/origin/* would become the remote-tracking branches refs/remotes/origin/* in the resulting repository.  So perhaps doing that against the bundle file would do what you wanted to do?  If that is the case, then perhaps your use case was covered by the original design of the \"git bundle\" feature after all---to allow you to clone or fetch from the file as if you are cloning or fetching from the original repository.\n\nHTH.\n\n"},{"id":"528287","messageId":"87ldllw7jk.fsf@igel.home","threadId":"64265","inReplyTo":"BN0PR13MB5216EC49DD37699C766B8DD6BBE1A@BN0PR13MB5216.namprd13.prod.outlook.com","subject":"Re: [BUG] git clone from bundle with --all does not fetch all refs","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2025-10-08T18:51:59Z","receivedAt":"2025-10-08T18:52:17Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Okt 08 2025, Andrew Harmon wrote:\n\n> As an end user, I found this very surprising. I was expecting to call:\n> git clone <repo-bundle>\n> and have this behave just like:\n> git clone <ssh-or-https-target>\n\nIf you want that equivalency, then you need to create the bundle either\ndirectly from <ssh-or-https-target>, or a mirror clone thereof.  By\nusing a regular clone as the source for the bundle you already have a\ndifferent type of repository than the one you see at the\n<ssh-or-https-target>.\n\n> echo \"\"\n> echo \"Clone the repo via SSH\"\n> git clone git@UBUBEAR:external_sources/matrice_sq.git matrice_sq\n>\n> echo \"\"\n> echo \"View available remote branches\"\n> (cd matrice_sq && git branch -r)\n\nCompare the output of \"git ls-remote matrice_sq\" with the output of \"git\nls-remote git@UBUBEAR:external_sources/matrice_sq.git\"\nto see the difference between the two repositories.\n\n>\n> echo \"\"\n> echo \"Pack the bundle for offline distribution\"\n> (cd matrice_sq && git bundle create ../matrice_sq.bundle --all)\n\nThe bundle picks up the refs from your local clone matice_sq, which is\ndifferent from the list of refs you'll see in the external source.\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":"528291","messageId":"BN0PR13MB5216F02F4FD2C3F0FC0EA770BBE1A@BN0PR13MB5216.namprd13.prod.outlook.com","threadId":"64265","inReplyTo":"87ldllw7jk.fsf@igel.home","subject":"RE: [BUG] git clone from bundle with --all does not fetch all refs","fromName":"Andrew Harmon","fromEmail":"aharmon@signalquest.com","sentAt":"2025-10-08T19:19:29Z","receivedAt":"2025-10-08T19:19:41Z","isPatch":false,"sender":{"key":"aharmon@signalquest.com","avatar":null},"body":"> If you want that equivalency, then you need to create the bundle either\n> directly from <ssh-or-https-target>, or a mirror clone thereof.  By using a\n> regular clone as the source for the bundle you already have a different type\n> of repository than the one you see at the <ssh-or-https-target>.\n\nThank you! This explanation really helps. Creating the bundle from a mirrored clone of the ssh target is exactly what I needed. This could be clearer in the docs. Several hours of time with Google, Claude, and ChatGPT all failed to point me at this simple (and now obvious) explanation.\n\nI appreciate your help, and your dedication to the Git project.\n\nKind regards,\nAndrew\n\n-----Original Message-----\nFrom: Andreas Schwab <schwab@linux-m68k.org> \nSent: Wednesday, October 8, 2025 14:52\nTo: Andrew Harmon <aharmon@signalquest.com>\nCc: Junio C Hamano <gitster@pobox.com>; git@vger.kernel.org\nSubject: Re: [BUG] git clone from bundle with --all does not fetch all refs\n\nOn Okt 08 2025, Andrew Harmon wrote:\n\n> As an end user, I found this very surprising. I was expecting to call:\n> git clone <repo-bundle>\n> and have this behave just like:\n> git clone <ssh-or-https-target>\n\nIf you want that equivalency, then you need to create the bundle either directly from <ssh-or-https-target>, or a mirror clone thereof.  By using a regular clone as the source for the bundle you already have a different type of repository than the one you see at the <ssh-or-https-target>.\n\n> echo \"\"\n> echo \"Clone the repo via SSH\"\n> git clone git@UBUBEAR:external_sources/matrice_sq.git matrice_sq\n>\n> echo \"\"\n> echo \"View available remote branches\"\n> (cd matrice_sq && git branch -r)\n\nCompare the output of \"git ls-remote matrice_sq\" with the output of \"git ls-remote git@UBUBEAR:external_sources/matrice_sq.git\"\nto see the difference between the two repositories.\n\n>\n> echo \"\"\n> echo \"Pack the bundle for offline distribution\"\n> (cd matrice_sq && git bundle create ../matrice_sq.bundle --all)\n\nThe bundle picks up the refs from your local clone matice_sq, which is different from the list of refs you'll see in the external source.\n\n--\nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1 \"And now for something completely different.\"\n\n"}]}