RE: [BUG] git clone from bundle with --all does not fetch all refs

This is exactly my use case. I found that I also needed to do: git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*'

As an end user, I found this very surprising. I was expecting to call: git clone <repo-bundle> and have this behave just like: git clone <ssh-or-https-target>

Maybe 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.

FILE: bundle-demo.sh

#!/bin/bash

set -e

# cleanup from last run rm -rf matrice_sq*

echo "" echo "Clone the repo via SSH" git clone git@UBUBEAR:external_sources/matrice_sq.git matrice_sq

echo "" echo "View available remote branches" (cd matrice_sq && git branch -r)

echo "" echo "Pack the bundle for offline distribution" (cd matrice_sq && git bundle create ../matrice_sq.bundle --all) (cd matrice_sq && git bundle verify ../matrice_sq.bundle)

echo "" echo "Unpack the bundle on new machine" git clone matrice_sq.bundle matrice_sq.new (cd matrice_sq.new && git branch -r)

echo "" echo "Manually fetch refs from refs/remotes/origin/*" (cd matrice_sq.new && git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*') (cd matrice_sq.new && git branch -r)

-----Original Message-----
From: Junio C Hamano <gitster@pobox.com> 
Sent: Wednesday, October 8, 2025 13:24
To: Andrew Harmon <aharmon@signalquest.com>
Cc: git@vger.kernel.org
Subject: Re: [BUG] git clone from bundle with --all does not fetch all refs

Andrew Harmon <aharmon@signalquest.com> writes:

I did not say "github", though ;-)

Everything 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.

The 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.

For 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.

And if you want to copy the remote-tracking branches via "git clone" or "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.

Stepping back a bit, how would you make a more-or-less exact copy of an existing repository over the network? "git clone --mirror" is 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.

HTH.