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

Re: [PATCH v2] status: list unmerged files last

From
Jeff King <peff@peff.net>
Date
Sep 2, 2009, 01:15 UTC
Message-ID
<20090902011513.GA3874@coredump.intra.peff.net>
In-Reply-To
<7vtyzmxkpr.fsf@alter.siamese.dyndns.org>
On Tue, Sep 01, 2009 at 05:18:40PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> The "keeping related things together" argument does mean your v1 is better
> than this patch, as you had "unmerged" next to "changed but not updated".
> I personally think the "keep related things together" argument makes much
> more sense than the "close to the bottom is easier to cut and paste"
> argument, as I tend to focus at the top of the output when looking at the
> status output and almost never cut & paste using mouse (screen for
> rectangular cutting and pasting works wonderfully), but it probably is
> just me.  And remember that I am only just one of the users, nothing more.
> 
> Sadly, "keep related things together" and "as close to the bottom as
> possible" are not quite compatible, and we can pick one or the other, but
> not both.

Just my two cents (and I think I have as good a track record at UI design as Junio... ;) ):

I think "related things together" trumps "close to the bottom". Because the former is something that _always_ applies to your output, while the latter is catering to a particular use case and a particular screen setup.

In other words, why is the _bottom_ reserved for more important things instead of the _top_? If I have a tall terminal that is long enough to see the output, are you potentially making the important thing less obvious (because I tend to read the the output from top to bottom)? If I use a pager (either manually, because I have seen that the output is too long, or automatically via the pager.status config variable)? What about reading status output into an interface wrapper like "tig status"?

So while you may be helping some users, I tend to think you may be hurting others.

-Peff

PS I am also not entirely convinced that unmerged entries are somehow more important to call attention to in the list than other entries. But the above argues that even _if_ you think they are more important, it is still not necessarily a good thing to move them to the bottom.

Previous: bill lamNext: Junio C Hamano
Message 9 of 34 in “unmerged files listed in the beginning of git-status”
  1. bill lamSep 1, 2009
  2. Junio C HamanoSep 1, 2009
  3. Johannes SixtSep 1, 2009
  4. status: list unmerged files after staged filesJohannes Sixt, Sep 1, 2009
  5. Junio C HamanoSep 1, 2009
  6. status: list unmerged files lastJohannes Sixt, Sep 1, 2009
  7. Junio C HamanoSep 2, 2009
  8. bill lamSep 2, 2009
  9. Jeff KingSep 2, 2009
  10. Junio C HamanoSep 2, 2009
  11. Jeff KingSep 2, 2009
  12. Junio C HamanoSep 2, 2009
  13. Jeff KingSep 2, 2009
  14. David AguilarSep 2, 2009
  15. Jeff KingSep 2, 2009
  16. David AguilarSep 3, 2009
  17. Jeff KingSep 5, 2009
  18. Jeff KingSep 5, 2009
  19. 1/6 status: typo fix in usageJeff King, Sep 5, 2009
  20. 2/6 docs: note that status configuration affects only long formatJeff King, Sep 5, 2009
  21. Junio C HamanoSep 6, 2009
  22. 3/6 status: refactor short-mode printing to its own functionJeff King, Sep 5, 2009
  23. Junio C HamanoSep 6, 2009
  24. 4/6 status: refactor format option parsingJeff King, Sep 5, 2009
  25. 5/6 status: add --porcelain output formatJeff King, Sep 5, 2009
  26. 6/6 commit: support alternate status formatsJeff King, Sep 5, 2009
  27. Jeff KingSep 5, 2009
  28. Johannes SixtSep 2, 2009
  29. Mark BrownSep 2, 2009
  30. Jeff KingSep 2, 2009
  31. Mark BrownSep 2, 2009
  32. Jeff KingSep 5, 2009
  33. Mark BrownSep 5, 2009
  34. bill lamSep 2, 2009

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.