On 7/4/07, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Jan Hudec <bulb@xxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
