On 12/21/2017 10:39 AM, Jeff King wrote:
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).
I like that actually. Have the porcelain versions only use the
command line option and do what is asked. And let the short/long
forms use both the command line option and the config setting.
That makes it explicit for scripts that parse the output.
Thanks!
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
