PRs cross Gitea instances

[lunny]

• Currently only support PRs cross Gitea instances, if you want to interactive with another Gitea instances, you have to add that Gitea instances as OAuth2 sources.
• Gitea could allow a fork from another Gitea services, a list of Gitea instance OAuth2 will be displayed to chose and the current login user should have a link account to that OAuth2.
• When forking, two repositories will be created. One is a hide mirror repository, the mirror remote URL is the fork remote URL. Another is the fork repository, it's in fact forked from the hidden mirror repository but the UI displayed it forked from remote.
• When send commits to the forked repository, the comparison UI will display the hide mirror repository and the forked repository branch.
• When create a PR to the mirrored repository, a real PR will be sent to the remote Gitea instance via API and OAuth2 token.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

This sounds great.
I have a few questions, though.

How will it be assured that the hidden mirror is kept in sync with the remote?

How would it affect operations if the hidden mirror got out of sync? Probably some API work could to be done for the receiving end to determine if a recent version is targeted or not and refuse the PR based on that, I don't know.

Would it sync before every user action targeting the remote (such as opening a PR to a remote), potentially warning the user that their changes are targeting an old version of the branch?

Wouldn't it be wasteful to in fact create two clones of the same repo just to have the user open, say, a +1 -1 PR in the end? I know, their business, but still.

What if the remote repo is already huge, requiring twice the amount of disk space for this kind of operation locally (and excluding 100% deduplicated backups scenarios, in the backups area, too)?

I could imagine it might become a bottleneck for many in terms of federated collaboration in this manner, in effect preventing adoption.

[nils91]

This sounds great.

+1, that would make a great feature. How would that look in the UI though? If the repo is forked from another instance that should be displayed in the UI, but otherwise the process should be mostly the same as using forks/PRs locally.

[ ] Currently only support PRs cross Gitea instances, if you want to interactive with another Gitea instances, you have to add that Gitea instances as OAuth2 sources.

Is there any plan to support more than other Gitea instances in the future, for example by allowing to open PRs from URL?

How will it be assured that the hidden mirror is kept in sync with the remote?

The easiest way would be to use webhooks. So for example you add a webhook in the source repo that notifies the fork on the other instance about new commits. The fork then could update itself by using the existing API. The problem there could be that the source repo could get cluttered with webhooks when many forks exist. Also, keeping instances in sync that are not online 24/7 could require some more work.

Wouldn't it be wasteful to in fact create two clones of the same repo just to have the user open, say, a +1 -1 PR in the end? I know, their business, but still.

I guess by doing that its possible to reuse most of the current fork/PR logic, but i would also be interested if other solutions are possible.

What if the remote repo is already huge, requiring twice the amount of disk space for this kind of operation locally (and excluding 100% deduplicated backups scenarios, in the backups area, too)?

Would it be sufficent to do shallow copies for remote forks (git clone --depth=1)? That could help for repos that require a lot of disk space just for their history.