On Wed, 14 Apr 2010 21:10:35 +0200, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Mon, 12 April 2010, Sverre Rabbelier wrote: >> >> On Mon, Apr 12, 2010 at 01:21, Julian Phillips >> <julian@xxxxxxxxxxxxxxxxx> wrote: >> > Probably the biggest change from v1 is an expanded aim. Now the >> > output library >> > is aimed at controlling _all_ plubming output. This series includes a >> > patch for >> > ls-tree that has all it's output going through the library, and a >> > patch for >> > status that has all the --porcelain output going through the library. >> >> I like where this is going, a lot, especially since we don't have to >> convert everything in one go, but we can do it as desired, similar to >> optparsification. I still think more commands than just these two >> should be converted to validate the design though, perhaps something >> like 'git blame', or 'git for-each-ref'? > > I don't think it is needed for either command. I think that the ability to say that all plumbing output is available in a variety of standard outputs is potentially useful. In particular the ability to be able to parse the output of all plumbing commands directly into whatever native language the high-level tool is in using an already existing standard parser makes life easier for those writing the tool. > 'git blame' has --porcelain and --incremental output, which is line-based > and pretty much self-describing (with "header-name value" syntax for most > of it), and well documented. JSON output would only add unnecessary > chatter and different quoting rules. That depends really. If you are writing something to parse the output, and you already have a JSON parser available then it's the current output that has different quoting rules. ;) Anyway, I have already converted blame to use the library for both --porcelain and --incremental output, so it'll be in the next version of the patch series. So you can try before you buy ... > 'git for-each-ref' has both --format=<format> to allow to get data what > one needs, and in the format one wants (with e.g. %00 to reresent NUL), > and [--shell|--perl|--python|--tcl] for placeholders in <format> to be > quoted as string literals suitable for specified host language. Although > I am not sure if this option, meant to produce scriptlets, is used that > much/ note that there is not support for --json quoting, nor --xml > escaping. -- Julian -- 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