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

[Peter Hunkeler <phunsoft@gmx.net>]

Am 30.10.2021 um 23:25 schrieb Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> 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.
Being the OP of this thread, I have learnt that a) my case of
incorporating database changes very atypical to git, and b) automating
the inclusion of such changes *at commit time* is not the best option.
In my case, it is easy to run this very pre-commit script manually
before the commit. I don't see any benefit of adding whatever "tool" to
support this special case.
>   * 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.
This would make the bevahiour to be consistent, without officialy
supporting or rejecting  "git xyz" from withing the hook. Hopefully not
too complex to implement.

Thanks
Peter