From: Peter Hunkeler Date: Tue, 02 Nov 2021 13:13:40 GMT Subject: Re: Git not commiting anything if file created and "git add"ed in pre-commit hook is the only file in the staging area Message-ID: In-Reply-To: Am 30.10.2021 um 23:25 schrieb Junio C Hamano: > Johannes Sixt 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