Re: [Qgit RFC] commit --amend

Jan Hudec [off-list ref] writes:

On Wed, Jul 04, 2007 at 14:44:16 +0200, Marco Costalba wrote:

quoted

On 7/4/07, Junio C Hamano [off-list ref] wrote:

quoted

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 would prefer if there was something between git-commit-tree and git-commit.
There are several steps one has to do for commit, that are the same for most
ways of commit:
 - call pre-commit hook (unless --no-verify)
 - write-tree
 - commit-tree
 - update-ref
 - mv next-index index
 - call post-commit hook (unless --no-verify or unconditionally?)

Would factoring out such script from the end of git-commit.sh be accepted?

Or would it be possible to get just that from git-commit with right options?
Basically I need to replicate the logic with 

I would suggest a name git-commit-index. It would take the index to commit,
index to move in after commit, head to update, list of parents and commit
message on standard input (as commit-tree does).

Judging from the existing users (am, commit, filter-branch, and
merge), I would say "write-tree then commit-tree then
update-ref" sequence could be made to a new built-in plumbing if
you really wanted to.  "mv next-index index" and calling of
hooks definitely do _not_ belong there, though, since the hook
that needs to be called are different, and the caller of such a
plumbing command is very well equipped to do them by themselves
anyway.