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

Re: [Qgit RFC] commit --amend

From
MCMarco Costalba <mcostalba@gmail.com>
Date
Jul 4, 2007, 12:44 UTC
Message-ID
<e5bfff550707040544l6272bdeao3a891c1793d29eae@mail.gmail.com>
In-Reply-To
<7vy7hwlpo4.fsf@assigned-by-dhcp.cox.net>
On 7/4/07, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> 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):
>
Thanks for your explanation, of course ;-) I think you will agree that...
Show 6 quoted lines
>
> 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.
>

Why an 'end-user' should _erroneusly_ write '-F' option to 'git commit --amend' ?

An error IMHO could occur if user *forgets* to write something, not if he intentionally writes a very specific '-F' option, in that case I would say user knows what it writes.

And speaking about errors one can always write 'git reset HEAD^' with worst results.

Probably you agree it's very _artificial_ try to guess what is in the head of the user and what is not, especially if this guess is made by a tool.

So I would dare to say this could be a good occasion to remove that illusory and obscure check.

Show 6 quoted lines
> 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.
>
I always prefer qgit to use the highest level commands as possible because:

1- Less error prone 2- Easier to implement 3- More robust to API change 4- Less easy to break by changes in git.

Having said that, from '-F' option documentation:
-F <file>::
	Take the commit message from the given file.  Use '-' to
	read the message from the standard input.
Jan, what about to use '-' and feed message from stdin?
Indeed the full signature of run() is:
bool Git::run(SCRef runCmd, QString* runOutput, QObject* receiver, SCRef buf)

Where the last parameter 'buf' it's a string that, if not empty, is passed to the launched program stdin.

I don't know if it is already too late, but I would suggest to stick to git-commit if possible, I see only downsides in not doing so. But of course who writes the code decides.

Marco
Previous: Junio C HamanoNext: Jan Hudec
Message 10 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.