Jan Hudec <bulb@xxxxxx> writes: > On Wed, Jul 04, 2007 at 14:44:16 +0200, Marco Costalba wrote: >> On 7/4/07, Junio C Hamano <gitster@xxxxxxxxx> 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. - 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
