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

[Junio C Hamano <gitster@pobox.com>]

Andrew Harmon <aharmon@signalquest.com> writes:

> The experience of "cloning from bundle should be just like cloning
> from github" did not happen for me. Maybe I created the bundle
> wrong?

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

> See the workflow, below. Is the problem that refs are put in the
> bundle at refs/remotes/origin/* instead of refs/heads/*?

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.