An integration test could be added.

I have some tests and will add them (see Improve "merge upstream" (sync fork)#33148 )

But I am not sure whether we should still use the "add remote" trick here, it seems fragile and I am not sure whether it is really helpful in daily usage.

But I am not sure whether we should still use the "add remote" trick here, it seems fragile and I am not sure whether it is really helpful in daily usage.

This is really what I am concerned about before submitting the PR.

One more bug I found onservices/repository/merge_upstream.go:35, the current sync fork is not correct, should be base repo's defaultBranch.

https://github.com/orgs/community/discussions/11729

But I am not sure whether we should still use the "add remote" trick here, it seems fragile and I am not sure whether it is really helpful in daily usage.

This is really what I am concerned about before submitting the PR.

One more bug I found onservices/repository/merge_upstream.go:35, the current sync fork is not correct, should be base repo's defaultBranch.

https://github.com/orgs/community/discussions/11729

If you have more ideas about the problem, feel free to take#33148 (there are more tests, I could close my PR if you'd like to use it in your PR)

One more bug I found onservices/repository/merge_upstream.go:35, the current sync fork is not correct, should be base repo's defaultBranch.

https://github.com/orgs/community/discussions/11729

At the moment, there is something unclear in my mind.

There could be 2 behaviors:

1. "Sync fork" only sync the default branch (or name-matched branch), the current behavior:
   • The typical workflow is like this: the user forks the repo, then base repo's default changes a lot, then the user sync the default branch into the fork, and start a new branch from the fork's default branch.
   • In this case, if a user would like to update (sync) a PR, they could just go to the PR's page and click the "update" button there
2. "Sync fork" sync everything basing on the base repo's default branch (your suggestion?)
   • There will be more edge cases to handle conflicts, and it duplicates with the "update" button on the PR page.

I see~

For 1. I did not notice this is the intended behavior of Gitea right now, as I am studying the code, I refer to GitHub a lot, Github has
the Number 2 behavior, so I thought this was a kind of bug.

I think we can simplify this PR without this issue first.

One more bug I found on services/repository/merge_upstream.go:35, the current sync fork is not correct, should be the base repo's defaultBranch.

https://github.com/orgs/community/discussions/11729

If you have more ideas about the problem, feel free to take#33148 (there are more tests, I could close my PR if you'd like to use it in your PR)

I reviewed it, and this is nice, how can I use the test? Must you close it so that I can use it, or I can just reference it to create something likerepo_sync_fork_rest.py

Actually I am not sure which behavior is better for end users. Maybe following GitHub's behavior is better since it is widely used. 🤣

If you have more ideas about the problem, feel free to take#33148 (there are more tests, I could close my PR if you'd like to use it in your PR)

I reviewed it, and this is nice, how can I use the test? Must you close it so that I can use it, or I can just reference it to create something likerepo_sync_fork_rest.py

Some possible choices:

• You could merge my branch into yourshttps://github.com/wxiaoguang/gitea/tree/improve-merge-upstream
• Or just copy the code into your PR
• Or wait forWIP: Improve "merge upstream" (sync fork) #33148 to be merged
• Or I could merge the code into this PR and work together here.

If you don't mind, I think I can merge#33148 here, then we do not need to use a separate PR to handle the similar tests.

Made some new changes:

1. mergeWIP: Improve "merge upstream" (sync fork) #33148 and reuse the tests
   • the new case is covered byBaseChangeAfterHeadChange
2. use base repo's default branch to sync (as you suggested and as GitHub does)