On Thu, Dec 21, 2017 at 09:18:17AM -0500, Jeff Hostetler wrote: > > This patch will affect "git status --porcelain", too. That's not > > supposed to change in incompatible ways. I guess it's up for debate > > whether callers are meant to handle any arbitrary string inside the [] > > (we already show "[gone]" for some cases), since AFAICT the format of > > the tracking info is left completely vague in the documentation. > > > > (I'd also hope that everybody is using --porcelain=v2 if they can, but > > we should still avoid breaking v1). > > I hadn't intended to alter V1 output. I'll disable the new feature > when V1 is selected. To be clear, I am on the fence regarding the "is it a breaking change" line. Certainly if the caller says "--no-ahead-behind", I don't see any harm in doing what they asked. But one further complication is that this may be triggered by config. And that goes for --porcelain=v2, as well. Even though the v2 documentation specifically says "ignore headers you don't recognize", would any callers be confused if a header is omitted due to a user's config? I guess for "branch.ab", the answer is "probably not", since it is already documented to appear only if certain conditions are met. So probably "omit branch.ab" is an OK change, as is "add a new header". But I just wonder if it would be simpler to ignore the config entirely for porcelain outputs (and require the explicit command-line option). Personally, I am not a purist when it comes to config and plumbing, and I'd be fine with having the config impact v2 (it is a hint from the user that they do not want to spend time on the computation, so having scripts respect that would be what the user wants). If you really have a script that is unhappy missing "branch.ab", then you can either choose not to set that config, or you can fix the script to use "--ahead-behind" to override the config. But I'm not sure everybody in the community would necessarily agree with me. -Peff
