From: "Jeff King" <peff@xxxxxxxx>
On Fri, Oct 31, 2014 at 02:48:17PM -0700, Junio C Hamano wrote:
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.
It's an option, I'd been looking at sneaking the information into the
refs header section.
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-<.
I think you could use a similar NUL-trick to what we do in the online
I like this 'trick'. I'd not appreciated the use of the null separator
for breaking a line into separate strings that way before (I'd
understood it, just never appreciated it!).
protocol, and have a ref section like:
...sha1... refs/heads/master
...sha1... refs/heads/confused-with-master
...sha1... HEAD\0symref=refs/heads/master
The current parser reads into a strbuf up to the newline, but we
ignore
everything after the NUL, treating it like a C string. Prior to using
strbufs, we used fgets, which behaves similarly (you could not know
from
fgets that there is extra data after the NUL, but that is OK; we only
want older versions to ignore the data, not do anything useful with
it).
This certainly looks the way to go. The one extra question would be
whether the symref should be included by default when HEAD is present,
or only if there was possible ambiguity between the other listed refs.
Previously I'd assumed the latter. The former would appear stronger, as
long as the symref was within the listed refs, and excluded otherwise.
Philip
--
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