Re: [Qgit RFC] commit --amend
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 4, 2007, 19:51 UTC
- Message-ID
- <7vir90gd67.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20070704182806.GA3268@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
Show 26 quoted lines
> On Wed, Jul 04, 2007 at 14:44:16 +0200, Marco Costalba wrote: >> On 7/4/07, Junio C Hamano <gitster@pobox.com> wrote: >>> 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.