Strange behaviors of the Sync Fork feature

[changchaishi]

Description

There is a known issue that, when in a forked repository, we use GetUpstreamDivergingInfo->GetDivergingCommits to see if the forked branch needs to be synced.

However the GetDivergingCommits will not work completely (return code 128 when the forked branch is updated) because the forked branch does not have the reference tree of the base branch in the repo path. Results in some scenarios, the Sync fork button is not shown as expected.

I would like to work on this issue, and the following is my fix design:

• By reference to modules/git/repo_compare.go's GetCompareInfo, implement a temporary remote for the forked branch to make the git rev-list work.
• The rev-list for the forked branch and base branch is much alike a pull request without listing the file changes but getting the summary of the commit change.

---

This issue is related to #32769, if this is fixed, the improved GetDivergingCommits could help the other issue.

Gitea Version

34dfc25

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

dev container from ubuntu22.04

Database

SQLite

[lunny]

How did you reproduce this? Or can you reproduce this on the demo site?

[changchaishi]

Hi Lunny, I reproduced in demo site as follows, you can check the behavior, which can be divided into 2 problems.

Problem 1 - no fork info when the forked branch is updated and the latest

1. Create a repo called TestOrg/repo1, adding empty file 123.txt (ok)
2. Fork the repo to {User}/repo1 (ok)
3. Add a new file called 456.txt in TestOrg/repo1 - base ahead fork (ok)
4. Check {User}/repo1's fork status - present 1 commit behind (ok)
5. Add a new file called 789.txt in {User}/repo1 - forked branch updated (ok)
6. Check {User}/repo1's fork status - No fork status shown - suppose fork is still behind base (NOT ok)

Problem 2 - Continue 6. Update base branch will no longer show n commits behind base anymore

1. Back to TestOrg/repo1, add 012.txt - update base - suppose 2 commits ahead fork (ok)
2. Check {User}/repo1's fork status - shows You have new change on base - it is ok but not consistent

I suggest fixing the inconsistent behavior of the fork feature, caused by the current GetUpstreamDivergingInfo function.