I have some tests in my pre-commit hook which require the hash of the previous commit to work. By previous commit I mean the one that will become the parent of the commit that's being created right now.

Normally, I can just use git rev-parse HEAD. However, during an --amend commit, the HEAD points to the current commit which will be deleted and replaced and what I really need is HEAD^.

I also a little concerned about rebasing. I have no idea what weird things can happen then.

How can I reliably get the parent commit's hash (as described) in the pre-commit hook?

CodePudding user response：

Closest I can get is detect it after the fact, in a post-rewrite hook.

In the code, pre-commit is called before Git has even determined the parents. This looks arbitrary to me, the prepare_to_commit call could be moved one paragraph down and the parents passed as hook args without breaking backward compatibility except for some why-would-you-do-that cases, but that's not how it works now.

Real enforcement needs to be done in the publishing repo's pre-receive anyway, if detecting the fault in a post-rewrite and complaining about it to the user there, maybe reset --soft'ing back to the original to undo the change, isn't going to do it for you, maybe writing up a description of what you're really doing here and either a patch or a help-me missive would get it changed.