Re: Git not commiting anything if file created and "git add"ed in pre-commit hook is the only file in the staging area

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 30, 2021, 21:25 UTC
Message-ID: <xmqqlf2adx3e.fsf@gitster.g>
In-Reply-To: <4c88e2ae-e42f-491a-2b97-aa1f92c392d5@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 5 quoted lines

> 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.