PRs without forking

[qwerty287]

Feature Description

Currently, I need to fork a project to contribute. Unfortunately, forking is not a that nice way in some views:

1. it takes more disk space
2. it bloats my own repo lists
3. it is an extra step to do

What I think would be great is something that's similar to AGit with some differences. AGit is a nice idea, however, it has two main drawbacks:

1. not working from the web interface
2. the commands are very complex (sure, I can use git aliases, but I still have to specify push opts directly)

A workflow that would be nice is:

1. clone (original) repo & make changes on new branch
2. when pushing, push to a branch that is stored separately in the database to handle permissions and use a unique name (<username>/<original branch name>, issue would be if you use something like feature/cool-feature)
3. just handle like a normal branch - allow PRs, maybe issue refs and so on

Other things should be considered:

• add settings for non-repo-admin to allow adding collaborators or managing permissions for branches "owned" by yourself
• allow "branch transfers" like repo transfers

I know that this is a complete change to the way how Gitea (and most other forges) work, but for me - and probably most other too - it would be really nice.

Screenshots

No response

[lunny]

What's the difference from sending PR from the same repository?

[qwerty287]

Actually none, but

• you don't have write perms on the repository
• the branches have own permissions

[6543]

https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-released/#major-features

[6543]

aGit Workflow is already implemented

[qwerty287]

@6543 maybe you didn't read my description carefully, but:

What I think would be great is something that's similar to AGit with some differences. AGit is a nice idea, however, it has two main drawbacks:
1. not working from the web interface
2. the commands are very complex (sure, I can use git aliases, but I still have to specify push opts directly)

[6543]

I think it would be posible to have a option to allow anybody to write to a repo, but this whould have so many security issues, i dont know where to start.

If you propose a way how this securely would work please tell me :)

[tastytea]

Maybe a compromise could be to list forks in a different category (with an option to ”promote” them when the fork becomes a project on its own) and use Copy on Write copies on file systems that support it?

Maybe there could even be a prompt when you're trying to push to a repository you don't have access to, like: “You don't have access to this repository. Do you want to create a fork? [Y/N]”. Although this could cause problems with git interfaces that don't expect interactive prompts on push, like editor plugins.

[qwerty287]

@6543 my idea was mainly to give permissions not by repo, but per branch. I.e. everybody can create new branches in a repo, but only the branch creators can push to it (repo owners for example can't, if it's is not allowed). Branches are working then without a fork, and PRs can be created how it is possible right now with PRs with the same base/head repository. The only differences are

• everybody can create a new branch
• if you create a new branch, you have admin rights about the branch (but not about other repo units like issues, projects...)
  • means you can push to the branch, delete it, add collaborators, make it protected... (actually everything branch-related in the repo settings, but you can't change them for branches you didn't create or you need to be added as collaborator with admin rights).

@tastytea asking the user also has the issue with git remotes which can't be added from the remote, gitea would need some kind of "branch redirection" to redirect branches to corresponding forks.

[lunny]

@6543 my idea was mainly to give permissions not by repo, but per branch. I.e. everybody can create new branches in a repo, but only the branch creators can push to it (repo owners for example can't, if it's is not allowed). Branches are working then without a fork, and PRs can be created how it is possible right now with PRs with the same base/head repository. The only differences are

• everybody can create a new branch

• if you create a new branch, you have admin rights about the branch (but not about other repo units like issues, projects...)

  • means you can push to the branch, delete it, add collaborators, make it protected... (actually everything branch-related in the repo settings, but you can't change them for branches you didn't create or you need to be added as collaborator with admin rights).

@tastytea asking the user also has the issue with git remotes which can't be added from the remote, gitea would need some kind of "branch redirection" to redirect branches to corresponding forks.

It's too complex and it will be full of securities problems but less benefits.

[qwerty287]

I know that it's very complex, but if it's implemented properly, I don't see any security issues. However, I understand your concerns about this.

[6543]

if we would add as proposed we would have to rebuild the same system as we have with forks but within the repo and the two can have conflicts ... beside the "ownership" now is not that deterministic anymore, and what if a person want to delete a repo but a other has still a branch on it?!?

what about impersonating stuff - now we for sure can not detect that, because of the structure how git works

[6543]

- sorry - will leave to nothing but wasted time - if you like to know more indephs about why, just DM or search about "security stuff & github/gitea/gitlab" ...