Re: [PATCH v1 0/6] Porcelain Status V2
- From
Jeff King <peff@peff.net>
- Date
- Jul 20, 2016, 20:57 UTC
- Message-ID
- <20160720205753.GC578@sigill.intra.peff.net>
- In-Reply-To
- <578FD0B1.9030709@jeffhostetler.com>
On Wed, Jul 20, 2016 at 03:27:45PM -0400, Jeff Hostetler wrote:
Show 22 quoted lines
> > 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