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

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

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