On Wed, Feb 10, 2016 at 04:33:11PM +0100, Sebastian Schuberth wrote:
> > where two of the prefixes have nothing in the second slot. I expected
> > something more like:
> >
> > file:<filename>\t</value...>
> > blob:<blob>\t<value...>
> > stdin\t<value...>
> > cmd\t<value...>
> >
> > with a single delimited slot for the source, which can then be broken
> > down further if desired. I can't think of any reason to prefer one over
> > the other rather than personal preference, though. They can both be
> > parsed unambiguously.
>
> I also would have expected sopme like the latter, except that I'd also
> expect a colon after "stdin" and "cmd" (or "cmdline", as said above).
> I.e. the colon should be part of the prefix to mark it as such.
Yeah, I waffled on that. Having a colon means you can definitely parse
to the first ":" without looking at what the prefix is. But if you don't
know what the prefix is, I don't know what good that does you. IOW, I'd
expect it to be parsed like:
if (/^file:(.*)/) {
# source is file $1
} elsif (/^blob:(.*)/) {
# source is blob $1
} elsif (/^stdin/) {
# source is stdin
} elsif (/^cmdline/) {
# source is cmdline
} else {
die "eh? I don't know about $_ at all!"
}
That's perl, but I think most languages make prefix-parsing like that
easy. I dunno. I doubt it matters all that much, and we are deep into
personal preference. There's already plenty to bikeshed on the option
name :)
-Peff
--
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