On Wed, Jul 20, 2016 at 03:27:45PM -0400, Jeff Hostetler wrote: > > A totally reasonable response is "haha no. Please stop moving the > > goalposts". I just wanted to throw it out there as an option (and in > > case you are interested, to let you think about it before any more work > > goes into this direction). > > haha no.... :-) > > Short term, I'd rather nail down what I have now (both content-wise > and format-wise) and see how we like it. And have a follow-up task > to look at the --state header we spoke of earlier. And save the JSON > version as an independent task for later. > > I understand the motivation for a JSON option (and have thought > about it before) but I think it ought to be kept separate. > At a higher-level, it seems like a JSON option would be an > opportunity to start a project-wide conversation about formats, > consistency, plumbing, and etc. A top-down conversation if you > will about which commands will/won't get enhanced, legacy cruft > that would not need to be converted, JSON style and naming and > consistency issues, current best practices in the node/whatever > community, and etc. I could be wrong, but this feels like a > top-down feature conversation in a wider audience. I agree with everything you've said here. If we add JSON, we'd want to do it everywhere: lists of commits, lists of refs, status output, etc. I mentioned that somebody had asked me about it recently; they are working on a git client and finding that libgit2 is not serving their needs well, so they'd like to shell out to git more, and wanted to have a standard way to get the data back in. -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