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

Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written

From
ESEugene Sajine <euguess@gmail.com>
Date
Feb 3, 2010, 19:27 UTC
Message-ID
<76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com>
In-Reply-To
<32541b131002031057q866d3q95d0e80a0adf6c52@mail.gmail.com>
> Of course, in such editors you could just hit "space; backspace" and
> then save.  Sounds annoying?  Well, so does deleting all the lines in
> the commit message just to make it *not* amend.

That was exactly the starting point of my thoughts.Currently it forces user to be explicit if he wants to cancel the operation (rebase -i, or amend), instead of forcing user to be explicit to proceed.

Show 6 quoted lines
>
> To reiterate what I said earlier: the mtime idea isn't even
> automatically a bad one.  It's about as good as what currently exists,
> and the resulting rule (file content or mtime must be modified) is
> just as consistent as the current rule (file must be nonempty).  It's
> also arguably easier for new users to understand.
OK. Agree on that.
>
> But you can't just blindly change the system to always work in a
> different way.  People depend on the current behaviour.

I understand that pretty well. My logic is that the most used command which is affecting the three is "git commit", therefore this command workflow is pretty natural for all users, but the workflow of commit --amend and rebase -i which are also affecting the three is inconsistent with commit. The user interaction is not the same.

> Jeff King's script is a pretty cute solution that lets you have it your way with
> no changes to git, though.
Thanks to Jeff, I'll try it.
>
> Of course, this does open up the question of how to do any global UI
> design at all if a decision made once gets locked in forever.
100% agree, there is such question.
> The reason git is hard for new users is that its UI is crazy and
> confusing, but a major reason it keeps gaining in popularity is that
> once you learn git, you stick with it, because you don't have to
> relearn it with every new version.

I just didn't realize that this can be such a drastic change for users as well as technical difficulties related to the emacs and similar editors.

Thanks, Eugene

Previous: Avery PennarunNext: Avery Pennarun
Message 37 of 45 in “[BUG] - "git commit --amend" commits, when exiting the editor with no changes written”
  1. Eugene SajineFeb 2, 2010
  2. Jacob HelwigFeb 2, 2010
  3. Avery PennarunFeb 2, 2010
  4. Eugene SajineFeb 2, 2010
  5. Wincent ColaiutaFeb 2, 2010
  6. Eugene SajineFeb 2, 2010
  7. Erik Faye-LundFeb 2, 2010
  8. Wincent ColaiutaFeb 2, 2010
  9. Eugene SajineFeb 2, 2010
  10. Avery PennarunFeb 2, 2010
  11. Eugene SajineFeb 2, 2010
  12. Johannes SchindelinFeb 2, 2010
  13. Eugene SajineFeb 2, 2010
  14. Avery PennarunFeb 2, 2010
  15. Larry D'AnnaFeb 3, 2010
  16. Jeff KingFeb 3, 2010
  17. Jeff KingFeb 3, 2010
  18. Avery PennarunFeb 3, 2010
  19. Johannes SchindelinFeb 2, 2010
  20. Eugene SajineFeb 2, 2010
  21. Erik Faye-LundFeb 2, 2010
  22. Eugene SajineFeb 2, 2010
  23. Erik Faye-LundFeb 3, 2010
  24. Eugene SajineFeb 3, 2010
  25. SZEDER GáborFeb 3, 2010
  26. Matthieu MoyFeb 3, 2010
  27. aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes writtenJohannes Schindelin, Feb 3, 2010
  28. SZEDER GáborFeb 3, 2010
  29. Eugene SajineFeb 3, 2010
  30. Matthieu MoyFeb 3, 2010
  31. Eugene SajineFeb 3, 2010
  32. Jonathan NiederFeb 3, 2010
  33. Jonathan NiederFeb 3, 2010
  34. Wincent ColaiutaFeb 3, 2010
  35. Eugene SajineFeb 3, 2010
  36. Avery PennarunFeb 3, 2010
  37. Eugene SajineFeb 3, 2010
  38. Avery PennarunFeb 3, 2010
  39. Matthieu MoyFeb 3, 2010
  40. Johannes SchindelinFeb 2, 2010
  41. Eugene SajineFeb 3, 2010
  42. Johannes SchindelinFeb 3, 2010
  43. Paolo BonziniFeb 3, 2010
  44. Junio C HamanoFeb 2, 2010
  45. Avery PennarunFeb 2, 2010

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.