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

From: Philip Oakley <philipoakley@iee.org>
Date: Nov 2, 2014, 19:06 UTC
Message-ID: <F44397C122BB4E63B89EC9BE26007B2E@PhilipOakley>
In-Reply-To: <20141101033327.GA8307@peff.net>

From: "Jeff King" <peff@peff.net>

Show 7 quoted lines

> 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.

Show 7 quoted lines

>> 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!).

Show 15 quoted lines

> 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