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

[Junio C Hamano <gitster@pobox.com>]

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.

Thanks for the discussion so far.