On Wed, Feb 10, 2016 at 4:40 PM, Jeff King <peff@xxxxxxxx> wrote: >> > 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 IMO that's asking the wrong question. The question should not be "what good does it do if we add the colons also there", but "what justification do we have to introduce an inconsistency by not adding them". > 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 :) I agree the option wording mostly is personal preference. On the other hand, I find discussions like these often prematurely waved aside as bikeshedding, just because e.g. Perl can parse the one as good as the other. But it's not about Perl, it's about humans. IMO Git has historically made many mistakes by not caring enough about consistency in docs, command and command line option naming, so I don't see it as wasted time to discuss about things like this. -- Sebastian Schuberth -- 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