Andrew Keller <andrew.keller@xxxxxxxxxxxxxxxx> writes: > I have observed an interesting scenario. Here are example reproduction steps: > > 1. new repository > 2. create new pre-commit hook that invokes `git mv one two` > 3. touch one > 4. git add one > 5. git commit > > Expected outcome: In the commit message template, I expect to see > “Changes to be committed: new file: two" Expected outcome is an error saying "do not modify the index inside pre-commit hook", and a rejection. It was meant as a verification mechansim (hence it can be bypassed with --no-verify), not as a way to make changes that the user didn't tell "git commit" to make. It is just the implementation that dates back to the old days were too trusting that all users would behave (with its own definition of "behaving well", which may or may not match your expectation), did not anticipate that people would try to muck with the contents being commited in the hook, and did not implement such verification. -- 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