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

Re: git status in clean working dir

From
Mike Hommey <mh@glandium.org>
Date
Jul 22, 2008, 05:39 UTC
Message-ID
<20080722053921.GA4983@glandium.org>
In-Reply-To
<20080722044157.GA20787@sigill.intra.peff.net>
On Tue, Jul 22, 2008 at 12:41:57AM -0400, Jeff King wrote:
Show 37 quoted lines
> On Mon, Jul 21, 2008 at 07:40:28PM -0700, Junio C Hamano wrote:
> 
> > Actually, the situation is now even worse than I originally thought
> > especially with Jeff's pager.<cmd> patch on 'master' recently.  For
> > example, you can screw yourself quite badly by forcing diff-files used in
> > the scripts you run to page, defeating --exit-code option.  Which means
> 
> Actually, you could _always_ do that with "git -p diff-files". Which is
> obviously stupid, just as setting pager.diff-files is. In the reported
> case, though, "status" is broken, which we now do by default. So no
> stupidity required.
> 
> >  (2) Then why are we even allowing to configure the plumbing to page?
> 
>   1. Laziness. We just never marked which shouldn't be allowed to page.
>      But again, in this case, we have explicitly marked status as "this
>      should page" so I don't think this is a plumbing / porcelain thing.
>      Status fulfills both roles here (some people want it paged, because
>      they use it as porcelain, and some people want the exit code).
> 
>   2. We don't always know all git commands. We execute user scripts as
>      "git foo", but we don't know what they do. Worse than that, we have
>      to commit our pager choice early because we might be exec'ing (but
>      this is somewhat of an artifact of the way the code is structured,
>      and not necessarily an impossible obstacle).
> 
> > Should we maintain a table of commands that we allow paging to be
> > customized, and ignore pager.<cmd> for commands that are not in the list?
> 
> The patch below sets up the infrastructure, which is trivial. Note that
> this _doesn't_ handle the case of "git -p status", because we have to
> commit that choice at a different time (again, we might be able to
> overcome that with a little code restructuring).
> 
> This marks diff-files as FORBID_PAGER; I will leave it to others to
> fight about which commands should have it. But it doesn't make sense to
> mark "status" since some people obviously _want_ the paging there.
Why not "simply" forbid the pager when output is not a terminal ?
Mike
Previous: Jeff KingNext: Jeff King
Message 10 of 30 in “git status in clean working dir”
  1. David BremnerJul 21, 2008
  2. Junio C HamanoJul 22, 2008
  3. Abhijit Menon-SenJul 22, 2008
  4. Junio C HamanoJul 22, 2008
  5. Junio C HamanoJul 22, 2008
  6. Jeff KingJul 22, 2008
  7. Jeff KingJul 22, 2008
  8. Johannes SchindelinJul 22, 2008
  9. Jeff KingJul 22, 2008
  10. Mike HommeyJul 22, 2008
  11. Jeff KingJul 22, 2008
  12. Mike HommeyJul 22, 2008
  13. Jeff KingJul 22, 2008
  14. Jeff KingJul 22, 2008
  15. 1/2 run-command: add pre-exec callbackJeff King, Jul 22, 2008
  16. 2/2 spawn pager via run_command interfaceJeff King, Jul 22, 2008
  17. Jeff KingJul 22, 2008
  18. Pierre HabouzitJul 22, 2008
  19. Jeff KingJul 22, 2008
  20. Johannes SixtJul 22, 2008
  21. Jeff KingJul 22, 2008
  22. Johannes SixtJul 22, 2008
  23. Junio C HamanoJul 22, 2008
  24. Jeff KingJul 22, 2008
  25. David BremnerJul 22, 2008
  26. Johannes SixtJul 22, 2008
  27. Jeff KingJul 22, 2008
  28. Johannes SixtJul 22, 2008
  29. Ask Bjørn HansenJul 24, 2008
  30. Jeff KingJul 24, 2008

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.