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

Re: [PATCH] bash: offer to show (un)staged changes

From
Thomas Rast <trast@student.ethz.ch>
Date
Jan 18, 2009, 02:32 UTC
Message-ID
<200901180332.49489.trast@student.ethz.ch>
In-Reply-To
<7vvdsd1hur.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 11 quoted lines
> Thomas Rast <trast@student.ethz.ch> writes:
> 
> > I came up with this after sending two incomplete patches on the same
> > night, and really like it.  Perhaps others might find it useful.
> 
> Any patch worth discussing (on this list at least) would need a nontrivial
> commit log message that you need to really think while writing.  It is
> natural to assume people would be making them with their editor, not with
> "commit -m".  These two incomplete patches could have been avoided if you
> paid attention to the status output that is in the commit log message
> buffer.  Perhaps we should make it even louder in some way?

Actually I tend to write the commit (and message) sometime halfway through, and then amend the commit with fixes, docs and such, possibly tweaking the message if I need to. That night I just forgot to amend before format-patch, and there's no status message at that point which could have reminded me. So the *+ display is just what I needed; it shows the status right before I get a chance to format-patch (or whatever else command expects a commit).

[As a side note, this kind of workflow is what will probably prevent me from working with any other SCM in the near future. I simply cannot imagine going back to a world without add -p, commit --amend and rebase -i.]

That being said, I never look at that status message; so far I've been too lazy to make my emacs add syntax highlighting there, and without it, it's just a big chunk of text. In fact, for most commits the 1-2 file names completely drown in the big chunk of surrounding, invariant, instructions. If it becomes even louder in the ASCII dimension, that most likely means I'll just have to steer my eye away from it even harder to see the commit message I'm typing. Perhaps some colours would help, I should really try that.

Of course the real solution would be to hack less and sleep more, but who would want to do that?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Previous: Junio C Hamano
Message 22 of 22 in “bash: offer to show (un)staged changes”
  1. bash: offer to show (un)staged changesThomas Rast, Jan 18, 2009
  2. Junio C HamanoJan 18, 2009
  3. Thomas RastJan 18, 2009
  4. Shawn O. PearceJan 19, 2009
  5. Martin LanghoffJan 19, 2009
  6. Shawn O. PearceJan 19, 2009
  7. Mike HommeyJan 19, 2009
  8. Martin LanghoffJan 19, 2009
  9. Boyd Stephen Smith Jr.Jan 19, 2009
  10. Martin LanghoffJan 19, 2009
  11. Boyd Stephen Smith Jr.Jan 19, 2009
  12. bash: offer to show (un)staged changesThomas Rast, Jan 19, 2009
  13. bash: offer to show (un)staged changesThomas Rast, Feb 1, 2009
  14. Shawn O. PearceFeb 1, 2009
  15. bash: offer to show (un)staged changesThomas Rast, Feb 3, 2009
  16. Shawn O. PearceFeb 3, 2009
  17. Tuncer AyazFeb 1, 2009
  18. Junio C HamanoFeb 1, 2009
  19. Tuncer AyazFeb 2, 2009
  20. Tuncer AyazFeb 2, 2009
  21. Junio C HamanoJan 18, 2009
  22. Thomas RastJan 18, 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.