Subject: Re: [PATCH] use child_process_init() to initialize struct child_process variables

From: Junio C Hamano <[email-masked]>
Date: Fri, 31 Oct 2014 14:48:17 -0700

"Philip Oakley" <[email-masked]> 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-<.