I was implementing another gitremote-helper today and ran into what I think is the same problem. Since I've worked around the problem in my gitremote-helper successfully, I wanted to share what I've learned in case it can help git-remote-gcrypt.
When git push is run, for a non-forced push, it asks the gitremote-helper program for "list for-push". It then sends a "push" to it. And only after that does it go compare the list of refs it got with the list of refs it has asked to be pushed, and notice if the push would overwrite a ref. At that point, git pull will complain that refs were not able to be pushed. But actually nothing stopped the gitremote-helper from doing a push that overwrote a ref, effectively a force push. I think this is a bug in git. I can't imagine why it behaves this way. It requires that every gitremote-helper program effectively replicate git's own detection of a disallowed push, in order to reject the "push" with "error $ref" It is certainly possible for a gitremote-helper program to do that though. What I did is, when git runs "list for-push", I remember the refs that are on the remote. Then when git runs "push $src:$dst", (but not when it's a "+$src" forced push), I compare the sha of $src with the old ref I saw on the remote. If the shas are different, I check `git log --oneline $old..$src` -- if this outputs nothing, then history is not advancing and it refuses to push that ref, and reports the error to git. -- see shy jo
signature.asc
Description: PGP signature
