On Wed, Feb 10, 2016 at 04:57:00PM +0100, Sebastian Schuberth wrote: > >> 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". But I think it is only an inconsistency if your mental model of the format is "the source field is a prefix, a colon, and then an argument; sometimes we omit the colon if there is no argument". If your mental model is "the source field contains a type, followed by type-specific data", then it is not an inconsistency. It is simply context-sensitive. Now you can argue that context-sensitive things are bad, and I might agree with that. :) > 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. Oh, I agree that formats are worth discussing. It's just that I do not think either of the mental models above is better than the other. My point in mentioning perl is not that perl can do it, but rather the opposite: that _any_ language can do it. And I would even go so far as to say that humans parse context-sensitive things better than machines, because we simultaneously apply the semantic and syntactic parsing (so you see "stdin" and know because of its meaning that there is nothing left to parse; you don't need a trailing colon to tell you that). Or perhaps you mean "humans write the programs that machines use to parse, and we must make things regular and easy for them". I can somewhat buy that argument, though again, I think either is easy; it is mostly a matter of documenting the format's mental model. -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