Aborted client-side git push can cause server post-commit hooks to be aborted or skipped

[mqudsi]

• Gitea version (or commit ref): Gitea version 1.12.0+dev-306-ga97fe7695 built with GNU Make 4.2.1, go1.13.7 : bindata
• Git version: git version 2.22.0.rc0
• Operating system: Debian 10 Buster
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
  • Probably, but this is a timing-dependent "race condition" of sorts, making it hard to replicate
• Log gist:
  gitea.pushfail.log

Description

I created a new repository in the UI then from a remote client added the origin to an existing repository (git add remote origin ...) and pushed the local commit history (git push -u origin master).

The push was taking awhile so I wanted to rerun it with --verbose to see if I can catch the reason for the delay, so I aborted the push with ^C and pushed again with --verbose but it was too late, there were no changes to be pushed.

However, when navigating to the repository in the UI, the repository still appears "new", the commits are not reflected (just like in #3795). I've attached the log, but it looks like aborting the push either aborted the git post-commit hooks or else prevented them from being run.

I know this isn't the case with GitHub (I've aborted pushes at just about every stage of the process without any out-of-sync issues there); does gitea perform the database updates while the client is connected (i.e. synchronously)? There's still no way to trigger a reindex, so I'm not sure how to get the commits to show without adding and pushing a spurious commit just to get it to reindex (but this is minor).

Screenshots

The UI after the failed push:

and yet, as viewed from the bare git storage directory used by gitea on the server itself:

[zeripath]

I think this was likely caused by the deadlock fixed in #10283. Could you try this again on master.

[mqudsi]

It's hard to test, but I'll reopen if I run into it again.

I do believe that synchronously calling (even via http) the post-commit hooks with the client doing the push on hold is still a bug, though.

[zeripath]

Certain things need to be done synchronously, but, yes, we do too much.