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

Re: [Qgit RFC] commit --amend

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 4, 2007, 05:10 UTC
Message-ID
<7vy7hwlpo4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<20070702180309.GA4400@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
>> P.S: Why 'git-commit --amend -F' it's explicitely forbidden?

The reasoning goes like this (here, I am not particularly trying to justify it, but am merely explaining the original reasoning and intended use case as a historical background):

    To amend means to remove the tip commit, replace with a new
    one, possibly but not necessarily with a different tree from
    the removed one.
    Since you are "amending", the spirit of the commit you are
    going to create, in order to replace the old one, ought to
    be the same as the one being replaced.
    - You may be only adding a change that you forgot to add
      before making the previous commit (in which case your tree
      is slightly different, but what you are going to say in
      the commit log message is exactly the same), or
    - you may found a typo in the commit log message and trying
      to fix it (in which case your tree is identical but the
      commit log message would be slightly different).
    In either case, the resulting commit log message would be
    very similar to the existing one, so the tool helps you by
    letting re-use and re-edit the commit log message instead of
    forcing you to re-type it.

There is no room for -F, -c, nor -m to make sense for these use cases, and giving them to "commit --amend" is most likely a user error, and diagnozed as such, because "commit --amend" is an end-user level Porcelain program.

If you are popping one commit and replacing with a totally **unrelated** commit, that is not what --amend is about. What you are doing is "reset --soft HEAD^" followed by "add <something>" followed by "commit".

At the mechanical level, you could argue that --amend is doing the same thing. After all, that reset/add/commit sequence is exactly what is done by --amend internally.

But if a Porcelain like StGIT or Qgit would want to do that kind of operation for different use case than "amending", it can and should use plumbing commands, just like the implementation of "commit --amend" does, with different constraints and error checks.

Previous: Jan HudecNext: Marco Costalba
Message 9 of 17 in “[Qgit RFC] commit --amend”
  1. Jan HudecJun 10, 2007
  2. Marco CostalbaJun 10, 2007
  3. Jan HudecJun 11, 2007
  4. Marco CostalbaJun 11, 2007
  5. Marco CostalbaJun 11, 2007
  6. Jan HudecJul 1, 2007
  7. Marco CostalbaJul 1, 2007
  8. Jan HudecJul 2, 2007
  9. Junio C HamanoJul 4, 2007
  10. Marco CostalbaJul 4, 2007
  11. Jan HudecJul 4, 2007
  12. Junio C HamanoJul 4, 2007
  13. Marco CostalbaJul 6, 2007
  14. Jan HudecJul 5, 2007
  15. Marco CostalbaJul 6, 2007
  16. Jan HudecJul 8, 2007
  17. Marco CostalbaJul 8, 2007

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.