Johannes Sixt <j6t@xxxxxxxx> writes: > Even though the documentation does not say explicitly that the commit > must not be changed, it is implicit in the stated intent (that the > commit is only checked). Depending on that some particular behavior > works for you sometimes is then your own business, and when it breaks > you get to keep both parts. The above matches my _intention_ for the pre-commit hook when I added it in 2005, but there were enough people who wanted to abuse the interface that it no longer exactly matches the reality. It has been made usable to inspect the changes (which is the original purpose of the hook) and in addition, apply mechanical fixes on top, before making the commit. The story so far, however, is that the scenario that started this thread is not even that, if I understand it correctly. The question is: what should happen when *nothing* is different between the HEAD and the index, the user types "$ git commit" (no pathspec, no nothing, commit the index as-is, no --allow-empty option), and the pre-commit mucks with the index to "fix" the content in the index. Because we check if there is anything to commit before we invoke the pre-commit hook and then reject an empty commit based on that, we successfully reject the attempt to commit. This is in line even with the modern intention, as the mucking done by the hook cannot be "fixes" based on the observation of the changes made to the index by the user (e.g. "The user tries to add changes, with whitespace breakages, and then pre-commit hook notices. Instead of rejecting, it fixes the whitespace issues for the user" is the justifying use case behind the looser than the original "check only, no touching" definition). So ... > In conclusion, the pre-commit hook behaves as designed and nothing has > to be changed. ... in conclusion, pre-commit is *not* a place to make such a change that may be created by a script even when there is no human initiated change, and "git commit" is behaving as designed. But there are two things that are not solved yet. * It is *not* the ultimate goal of the OP to "use" pre-commit hook. The goal of OP is to find a workflow ingredient where changes other than human initiated ones are committed at the same time human user tries to commit changes created by human. So if pre-commit is the wrong tool to use for that purpose, what is it? I suspect that there is no built-in way to do this, and I am not sure if it is a good idea to add such a feature to the tool---as some have already noted in the discussion, it may encourage a bad workflow to include such non-human-created artifacts to human initiated commit. I don't know. * If we do not consider changes made by pre-commit hook to count as "without --allow-empty, an empty commit is rejected" logic, why do we even call the hook in the first place in such a case? I think there is a room for improvement on our side---perhaps we can make "git commit" fail much earlier in such a case without calling the pre-commit hook. Thanks for the discussion so far.
