Re: [PATCH 0/8] Add 'ls-files --json' to dump the index in json

From: Jeff King <peff@peff.net>
Date: Jun 21, 2019, 20:51 UTC
Message-ID: <20190621205150.GC25874@sigill.intra.peff.net>
In-Reply-To: <nycvar.QRO.7.76.6.1906211515160.44@tvgsbejvaqbjf.bet>

On Fri, Jun 21, 2019 at 03:16:52PM +0200, Johannes Schindelin wrote:

Show 12 quoted lines

> > 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.

> 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'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.

-Peff