Move git config/remote to gitrepo package and add global lock to resolve possible conflict when updating repository git config file

[lunny]

Partially fix #32018

git config and git remote write operations create a temporary file named config.lock. Since these operations are not atomic, they must not be run in parallel. If two requests attempt to modify the same repository concurrently—such as during a compare operation—one may fail due to the presence of an existing config.lock file.

In cases where config.lock is left behind due to an unexpected program exit, a global lock mechanism could allow us to safely remove the stale lock file when a related error is detected. While this behavior is not yet implemented in this PR, it is planned for a future enhancement.

[wxiaoguang]

No, it doesn't fix #32018

[wxiaoguang]

Don't see why it is worth or right to do so, and don't see why it fixes that issue

[lunny]

Don't see why it is worth or right to do so, and don't see why it fixes that issue

git config and git remote write operations create a temporary file named config.lock. Since these operations are not atomic, they must not be run in parallel. If two requests attempt to modify the same repository concurrently—such as during a compare operation—one may fail due to the presence of an existing config.lock file.

In cases where config.lock is left behind due to an unexpected program exit, a global lock mechanism could allow us to safely remove the stale lock file when a related error is detected. While this behavior is not yet implemented in this PR, it is planned for a future enhancement.

[wxiaoguang]

So it is an improvement but doesn't "Fix #32018", right?

But does it really need the "global lock"? Is it possible that git already uses "*.lock" files by flock for global lock? Then Gitea shouldn't do anything more?

[lunny]

So it is an improvement but doesn't "Fix #32018", right?

But does it really need the "global lock"? Is it possible that git already uses "*.lock" files by flock for global lock? Then Gitea shouldn't do anything more?

The Git command-line interface is primarily designed for human interaction. When a git config write operation is initiated and a config.lock file is created, any subsequent git config write operation will immediately fail instead of waiting for the first one to complete.

While I couldn’t find official documentation confirming this behavior, the implementation can be found in the Git source code here:
https://github.com/git/git/blob/97e14d99f6def189b0f786ac6207b792ca3197b1/config.c#L3199

Based on this, it appears that Git does not implement a locking mechanism that causes subsequent operations to wait—it simply fails fast.

I believe this change partially addresses #32018, as there are three possible causes for the issue:

• Concurrent requests attempting to compare between the same base and forked repositories.
• A Git command exits unexpectedly, leaving behind a config.lock file. I plan to implement automatic cleanup of stale config.lock files in another PR, which would help resolve this case.
• An administrator manually runs Git commands on the Gitea server. This scenario is outside the scope of this PR, and I don’t believe it’s something we can reliably handle within the application.

[wxiaoguang]

Git already does a file-based "global lock"

https://github.com/git/git/blob/master/lockfile.c#L104 (config.c hold_lock_file_for_update -> lockfile.c lock_file_timeout )

I do not think this PR is worth or right.

---

Update: git passes timeout=0, so it only locks "once"

dismiss

[wxiaoguang]

I don't think it is right to use global lock for long-time running commands.

[lunny]

98bc0df