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
Jeff King <peff@peff.net>
Date
Dec 21, 2017, 15:39 UTC
Message-ID
<20171221153950.GA14411@sigill.intra.peff.net>
In-Reply-To
<1c019725-7715-496e-bad6-9d47d2bae834@jeffhostetler.com>
On Thu, Dec 21, 2017 at 09:18:17AM -0500, Jeff Hostetler wrote:
Show 11 quoted lines
> > 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
Previous: Jeff HostetlerNext: Jeff Hostetler
Message 5 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.