New pull request notification will show wrong branch in a special case

[yp05327]

Description

Sorry, this is a bug come from my PR #25812

Reproduce:

1. create a new repo A, create a file in it
2. fork it to repo B
3. push a commit (the most easy way is creating a new file in web) in repo A's main branch

Then you will see:
In repo A, the branch in notification is repo B's main branch, actually the expected branch is repo A's main branch.

In the fork (repo B), it show the repo A's main branch, actually the expected behavior is showing nothing.

Reason:
For newly created empty branch (based on default branch), I want to ignore the notification, so I added this in the SQL query.

And this cause this bug.

In repo A, it will ignore the newly pushed commit because of the condition I mentioned above, and the default branch's latest commit id is changed. So in repo B's main branch, the latest commit id is not same to the repo A's default branch's latest commit id, so it will be picked up as a recently updated branch.

Don't have a good idea about how to fix it now. If someone is interested, it is welcome to create a PR for it.

Gitea Version

latest

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?

build

Database

None

[cclvi256]

In my trial like this, only the picture 2 is successfully re-produced, and there's nothing like the senario like picture 1. And I reckon that this is just normal.

By the way, maybe we can add a button to "Syncronise Forked Repository" like GitHub.

[lunny]

By the way, maybe we can add a button to "Syncronise Forked Repository" like GitHub.

The feature has been implemented which will be released in v1.23.0

[changchaishi]

The feature has been implemented which will be released in v1.23.0

Hi @lunny, may I ask if the release will include the fix to this issue? If not, I would like to work on this issue.

[lunny]

The feature has been implemented which will be released in v1.23.0

Hi @lunny, may I ask if the release will include the fix to this issue? If not, I would like to work on this issue.

I don't think so. I just answered the off-topic question. You are welcome to send a pull request.

[yp05327]

@changchaishi
You can ask @lunny assigning this issue to you, if you are interested in fixing it.
As there's no PR now, everyone can send a PR to fix it. But if someone is assigned, then others may not work on it any more.
Also it is not related to the schedule of the release. If the PR can be finished and merged before the release, then it will be included.

ps: I have no idea about how to fix it, it is really complex. I'm looking forward to the solution.

[changchaishi]

Hi sharing my thoughts here.

Maybe it is not as hard as it seems, as in the branches view, we already have logic that tells whether a branch is worth a PR for the base branch. We can transplant this logic from to forked repo branch to the base default branch. So we always catch the right branches to show.

Simply put, the behavior should be:

• target's commit to the branch is fresh (less than 2 hours)
• Then do a GetUpstreamDivergingInfo for the ahead counter
  • if any ahead to the base branch is greater than 0, include them
• the rest follow the current prepareRecentlyPushedNewBranches filter logic

Could this be the solution?

[yp05327]

Could this be the solution?

Send a PR with a test for this case is the simple way I think.