git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/4] status: update short status to use --no-ahead-behind

From
JHJeff Hostetler <git@jeffhostetler.com>
Date
Dec 21, 2017, 17:47 UTC
Message-ID
<54aad332-cb74-345d-4bed-96f0814a804f@jeffhostetler.com>
In-Reply-To
<20171221153950.GA14411@sigill.intra.peff.net>
On 12/21/2017 10:39 AM, Jeff King wrote:
Show 29 quoted lines
> 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!
Show 12 quoted lines
> 
> 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
>
Previous: Jeff KingNext: Jeff Hostetler
Message 6 of 17 in “Add --no-ahead-behind to status”
  1. 0/4 Add --no-ahead-behind to statusJeff Hostetler, Dec 20, 2017
  2. 3/4 status: update short status to use --no-ahead-behindJeff Hostetler, Dec 20, 2017
  3. Jeff KingDec 20, 2017
  4. Jeff HostetlerDec 21, 2017
  5. Jeff KingDec 21, 2017
  6. Jeff HostetlerDec 21, 2017
  7. 2/4 stat_tracking_info: return +1 when branch and upstream differJeff Hostetler, Dec 20, 2017
  8. Jeff KingDec 20, 2017
  9. Jeff KingDec 20, 2017
  10. Jeff HostetlerDec 21, 2017
  11. 1/4 status: add --no-ahead-behind to porcelain V2Jeff Hostetler, Dec 20, 2017
  12. Jeff KingDec 20, 2017
  13. Jeff KingDec 20, 2017
  14. Jeff HostetlerDec 20, 2017
  15. 4/4 status: support --no-ahead-behind in long status format.Jeff Hostetler, Dec 20, 2017
  16. Jeff KingDec 20, 2017
  17. Jeff KingDec 20, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.