Am 30.10.2021 um 23:25 schrieb Junio C Hamano:
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.
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
