On 25/02/05 05:18AM, Junio C Hamano wrote: > Justin Tobler <jltobler@xxxxxxxxx> writes: > > > One concern I currently have with this quoting approach is that it is a > > bit more challenging to machine parse compared to something like using a > > null byte to delimit between missing info. One option is, in a followup > > series, introduce a git-for-each-ref(1) style format syntax. Maybe > > something like: `--missing=print-info:%(path)%00%(type)`. I'm curious if > > anyone may have thoughts around this. > > Would it be so bad if we said that in -z mode with --info option, > each record is terminated with two NUL bytes, and elements on a list > of var=value pairs have a single NUL in between, or something silly > like that? The point is to get away with just a fixed format, > without any customization. I agree that some sort of fixed format would be preferable as it's less complex while also being simpler to implement. I originally considered using NUL but realized a single NUL byte to delimit between entries wouldn't be sufficient to determine where each record would end. Using two NUL bytes next to each other to mark the end of a record would work though. Since even a normal rev-list record may have an object name entry in addition to its OID when the `--objects` option is set, maybe we could introduce a `-z` option that always terminates a record with two NUL bytes? The output for `git rev-list -z --objects --missing=print-info` could look something like the following (no LF at EOL): 6aa71444d3d41315509c3f2cfe2d45d86cea20d7<NUL><NUL> f009994f5d7fc97c1e87b4dc7ad69057a07e85c4<NUL>foo/bar<NUL><NUL> ?f10f78c60046b2be841c9e2403960663439296c3<NUL>path=foo/bar/baz<NUL>type=blob<NUL><NUL> ?ead43a34efd775b58d6b3e86db6bc71bbedd2c1c<NUL>path=foo/bar/baz 2<NUL>type=blob<NUL><NUL> Having two NUL bytes to delimit between records might be a bit odd in the common case for git-rev-list(1) without the `--objects` and `--missing` options since we would only expect a list of OIDs. Having consistent `-z` option output irrespective of other options might be preferable though. If this approach seems reasonable, I can do so in a followup series. Thanks -Justin
