From: Marco Costalba <mcostalba@gmail.com>
Date: Wed, 04 Jul 2007 12:44:16 GMT
Subject: Re: [Qgit RFC] commit --amend
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:
> 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...

>
> 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.

> 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