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

New Issue

GiteaMirror · 2025-11-02T06:05:08-06:00

GiteaMirror commented

2025-11-02 06:05:08 -06:00

Originally created by @mqudsi on GitHub (Feb 14, 2020).

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:

Originally created by @mqudsi on GitHub (Feb 14, 2020). - 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 - [X] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - [X] Probably, but this is a timing-dependent "race condition" of sorts, making it hard to replicate - Log gist: [gitea.pushfail.log](https://github.com/go-gitea/gitea/files/4207345/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](https://github.com/go-gitea/gitea/issues/3796), 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: ![image](https://user-images.githubusercontent.com/606923/74576467-85dc3280-4f50-11ea-9219-51c48107350a.png) and yet, as viewed from the bare git storage directory used by gitea on the server itself: ![image](https://user-images.githubusercontent.com/606923/74576502-a99f7880-4f50-11ea-9164-21f74a102b5e.png)

GiteaMirror added the type/bug label 2025-11-02 06:05:08 -06:00

GiteaMirror closed this issue

2025-11-02 06:05:08 -06:00

GiteaMirror commented

2025-11-02 06:05:09 -06:00

@zeripath commented on GitHub (Feb 16, 2020):

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

@zeripath commented on GitHub (Feb 16, 2020): I think this was likely caused by the deadlock fixed in #10283. Could you try this again on master.

GiteaMirror commented

2025-11-02 06:05:09 -06:00

@mqudsi commented on GitHub (Feb 16, 2020):

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.

@mqudsi commented on GitHub (Feb 16, 2020): 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.

GiteaMirror commented

2025-11-02 06:05:09 -06:00

@zeripath commented on GitHub (Feb 16, 2020):

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

@zeripath commented on GitHub (Feb 16, 2020): Certain things need to be done synchronously, but, yes, we do too much.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#4858

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

Description

Screenshots

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