Chris Torek <chris.torek@xxxxxxxxx> writes: > It would in theory be possible for Git to load *the* index twice, > once before and once after the hook, and compare them to see what > changed, then perhaps try to use that change to update the > additional indices. That would be a pretty big change, but if it > were done right, it might get what you want. FYI, we tried not to do the extra re-reading, because pre-commit hook was designed to be a mechanism to allow users to validate, but not correct, what gets committed. As the system originally was designed, users who correctly use Git would *not* be modifying the index. Because it is an error to modify the index in the hook, (1) re-reading the index just in case the user commits such a mistake is waste of resources, and (2) checking the index to make sure it did not change before and after invoking the hook, again, is also waste of resources. It may have been a mistake that we re-read the index in some case, which adds to the confusion, but not others.
