PRs without forking #8785

New Issue

GiteaMirror · 2025-11-02T08:17:49-06:00

GiteaMirror commented

2025-11-02 08:17:49 -06:00

Originally created by @qwerty287 on GitHub (Apr 4, 2022).

Feature Description

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

it takes more disk space
it bloats my own repo lists
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:

not working from the web interface
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:

clone (original) repo & make changes on new branch
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)
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

Originally created by @qwerty287 on GitHub (Apr 4, 2022). ### 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_

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:17:49 -06:00

GiteaMirror closed this issue

2025-11-02 08:17:50 -06:00

GiteaMirror commented

2025-11-02 08:17:51 -06:00

@lunny commented on GitHub (Apr 4, 2022):

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

@lunny commented on GitHub (Apr 4, 2022): What's the difference from sending PR from the same repository?

GiteaMirror commented

2025-11-02 08:17:51 -06:00

@qwerty287 commented on GitHub (Apr 4, 2022):

Actually none, but

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

@qwerty287 commented on GitHub (Apr 4, 2022): Actually none, but * you don't have write perms on the repository * the branches have own permissions

GiteaMirror commented

2025-11-02 08:17:51 -06:00

@6543 commented on GitHub (Apr 4, 2022):

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

@6543 commented on GitHub (Apr 4, 2022): https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-released/#major-features

GiteaMirror commented

2025-11-02 08:17:51 -06:00

@6543 commented on GitHub (Apr 4, 2022):

aGit Workflow is already implemented

@6543 commented on GitHub (Apr 4, 2022): aGit Workflow is already implemented

GiteaMirror commented

2025-11-02 08:17:52 -06:00

@qwerty287 commented on GitHub (Apr 4, 2022):

@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)

@qwerty287 commented on GitHub (Apr 4, 2022): @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) ```

GiteaMirror commented

2025-11-02 08:17:52 -06:00

@6543 commented on GitHub (Apr 4, 2022):

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 :)

@6543 commented on GitHub (Apr 4, 2022): 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 :)

GiteaMirror commented

2025-11-02 08:17:53 -06:00

@tastytea commented on GitHub (Apr 4, 2022):

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.

@tastytea commented on GitHub (Apr 4, 2022): 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.

GiteaMirror commented

2025-11-02 08:17:53 -06:00

@qwerty287 commented on GitHub (Apr 4, 2022):

@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.

@qwerty287 commented on GitHub (Apr 4, 2022): @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.

GiteaMirror commented

2025-11-02 08:17:54 -06:00

@lunny commented on GitHub (Apr 5, 2022):

@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.

@lunny commented on GitHub (Apr 5, 2022): > @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.

GiteaMirror commented

2025-11-02 08:17:54 -06:00

@qwerty287 commented on GitHub (Apr 5, 2022):

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.

@qwerty287 commented on GitHub (Apr 5, 2022): 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.

GiteaMirror commented

2025-11-02 08:17:57 -06:00

@6543 commented on GitHub (Apr 5, 2022):

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 commented on GitHub (Apr 5, 2022): 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

GiteaMirror commented

2025-11-02 08:17:57 -06:00

@6543 commented on GitHub (Apr 5, 2022):

- 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" ...

@6543 commented on GitHub (Apr 5, 2022): ` - 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" ...

GiteaMirror commented

2025-11-02 08:17:57 -06:00

@luwol03 commented on GitHub (Apr 5, 2022):

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) [...]
@tastytea

I like that idea and think we should open that as a new issue.

@luwol03 commented on GitHub (Apr 5, 2022): > 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) [...] @tastytea I like that idea and think we should open that as a new issue.

GiteaMirror commented

2025-11-02 08:17:57 -06:00

@6543 commented on GitHub (Apr 5, 2022):

and use Copy on Write copies

git already do this if you have a btrfs,...

... open that as a new issue.

that would be an UI/UX idea ... go on with it - some sketch "draft" views would be awesome in this case too

*sketch = painted / screenshot of gitea with custom css / picutre created with gimp / ...

@6543 commented on GitHub (Apr 5, 2022): > and use Copy on Write copies git already do this if you have a btrfs,... > ... open that as a new issue. that would be an UI/UX idea ... go on with it - some sketch "draft" views would be awesome in this case too *sketch = painted / screenshot of gitea with custom css / picutre created with gimp / ...

GiteaMirror commented

2025-11-02 08:17:58 -06:00

@luwol03 commented on GitHub (Apr 5, 2022):

Created one to continue discussion there: https://github.com/go-gitea/gitea/issues/19327

@luwol03 commented on GitHub (Apr 5, 2022): Created one to continue discussion there: https://github.com/go-gitea/gitea/issues/19327

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8785