Hi Duy, On Fri, 21 Jun 2019, Duy Nguyen wrote: > On Fri, Jun 21, 2019 at 8:16 PM Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > I think your warning in the manpage that this is for debugging is fine, > > > as it does not put us on the hook for maintaining the feature nor its > > > format forever. We might want to call it "--debug=json" or something, > > > though, in case we do want real stable json support later (though of > > > course we would be free to steal the option then, since we're making no > > > promises). > > > > Traditionally, we have not catered well to 3rd-party applications in Git, > > and this JSON format would provide a way out of that problem. > > > > So I would like *not* to lock the door on letting this feature stabilize > > organically. > > > > I'd be much more in favor of `--json[=<version>]`, with an initial version > > of 0 to indicate that it really is unstable for now. > > Considering the amount of code to output these, supporting multiple > formats would be a nightmare. I may be ok with versioning the output > so the tool know what format they need to deal with, but I'd rather > support just one version. Once the format stabilized, I don't think it would be a huge burden to support multiple formats, if we ever had to update. It would, however, be a huge burden on third-party applications. In effect, we could be lazy, but we would put a lot more burden on others than we saved ourselves, so that would be a bit... selfish. > For third parties wanting to dig deep, I think libgit2 would be a much > better fit. If we (i.e. the core Git contributors) were contributing new features/bug fixes to libgit2, that would be a good recommendation. But we don't. We essentially ignore libgit2 (and all of their learnings) all the time. Even worse, for years, even decades, we recommended the command-line as "the API". If you want to reverse that recommendation, I think it merits a bigger discussion than a flimsical comment buried in a thread about an experimental feature. Ciao, Dscho
