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 commit which will be deleted and replaced, so 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?
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.