"Philip Oakley" <philipoakley@xxxxxxx> writes: > As a side project (slow time) I've been looking at the loss of the > HEAD symbolic ref when multiple heads are bundled that point at the > same rev. That is, when the HEAD detection heuristic fails. It think you are talking about the logic used by the "clone", where - if there is only one branch ref that matches the value of HEAD, that is the branch; - if there are more than one refs that match the value of HEAD, and if one of them is 'master', then that is the branch; - if there are more than one refs that match the value of HEAD, and if none of them is 'master', then pick the earliest one. So you would be in trouble _if_ you have two refs pointing at the same commit, one of them being 'master', and the current branch is the other ref. All other cases you shouldn't have to change the file format and have older client understand which branch is the current one. Programs that read a pack data stream unpack-objects were originally designed to ignore cruft after the pack data stream ends, and because the bundle file format ends with pack data stream, you should have been able to append extra information at the end without breaking older clients. Alas, this principle is still true for unpack-objects, but index-pack broke it fairly early on, and we use the latter to deal with bundles, so we cannot just tuck extra info at the end of an existing bundle. You'd instead need a new option to create a bundle that cannot be read by existing clients X-<. -- 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