"Philip Oakley" <philipoakley@xxxxxxx> writes: >>> You probably wanted "git bundle create ../repo.bundle --all" which >>> includes both "master" and "HEAD". >> >> That explains it, thanks! Maybe this could be added as an example to >> the >> documentation for `git bundle`? People looking at `man git-bundle` >> hoping >> to use it as one possible way to make a backup of a Git repository >> might >> not realize right away that --all is the way to specify all refs, like >> with `git log`. > > I had posted a documentation patch back in Setemeber last year, > http://thread.gmane.org/gmane.comp.version-control.git/205887/focus=205897, > however Junio highlighted some additional concerns that I wasn't able > to respond to at the time. > > It may be worth resurrecting once the concerns have been addressed. A saner thing to do, instead of explaining away the lack of HEAD as "the creator of the bundle did not bother to name it", might be to automatically add an artificial HEAD to the resulting bundle when the arguments given to specify the "range" do not have any negative ones (because by definition such a bundle is unsuitable for use with "git clone" [*1*]), and HEAD is not among the refs. The heuristics to pick what to record as the artificial HEAD could vary, though. Without thinking things through... * When only one positive ref is given, use it (sort of obvious); * When two or more positive refs are given, and the current branch is one of them, use that; * Otherwise, pick the "first" positive ref given from the command line. perhaps? [Footnote] *1* Strictly speaking, this condition could be loosened, as long as cloning side uses an appropriate --depth, but I do not know such an "advanced use case" needs a hand-holding change to add a HEAD that was not asked by the user. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html