Hi Peff, On Fri, 21 Jun 2019, Jeff King wrote: > On Fri, Jun 21, 2019 at 03:16:52PM +0200, Johannes Schindelin 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 like it to stabilize organically, too, but my thinking was that we'd > wait a while and then promote it to a stable name eventually. Git's command-line options have stabilized organically. Example: to include untracked files in `git stash`, use `-u` or `--include-untracked`, to include them in `git add`, use `-A` or `--all`, to include them in `git grep`, use `--untracked` (no short option), to include them in `git ls-files`, use `-o` or `--others`. The command `git commit` does not even have an option to include untracked files. You know of more examples of organically grown designs in Git, I am sure. Given those examples, I am not sure that I want the JSON format to 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. > > That's OK with me, too, if you think "0" indicates that sufficiently > (we've used "v0" in a lot of other places to refer to stable protocols, > like the git:// one). Maybe it's OK with some documentation making it > clear. I did think that the `0` would be clear, but you are probably right. > I'm not sure whether we want to be locked into supporting this v0 > forever or not (though maybe it would not be such a burden). > > I think JSON-based output also has the potential to need fewer bumps. > It's syntactically stable, so it's really just about our schema. And > it's easy to say "newer versions of Git may produce new keys; you can > ignore them", as long as we do not change the meaning of existing keys. > That might be an easier promise to make. Right. Thanks, Dscho
