If your change were so that "git commit --interactive" reverts the index
when one of the hooks exited non-zero just like COMMIT_NORMAL case (as
opposed to the current code which does not revert the index), I would
understand the need to change what's inside "if (interactive)" block.
So why does the COMMIT_AS_IS path need to lock? The comment is not clear:
* The caller should run hooks on the real index, and run
* hooks on the real index, and create commit from the_index.
* We still need to refresh the index here.
It seems to me that the lock+refresh+write+commit done by plain "git
commit" is useless too, since it also runs in the case "pathspec &&
*pathspec".
I guess the patch should be withdrawn, and so I didn't want to follow up
anymore, but the weird comment made me change my mind...
(The other patch I sent -- which is at
http://permalink.gmane.org/gmane.comp.version-control.git/83209 -- is
not withdrawn and not related to this one).
Paolo
--
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
