Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PRs without forking #19322

Closed
qwerty287 opened this issue Apr 4, 2022 · 15 comments
Closed

PRs without forking #19322

qwerty287 opened this issue Apr 4, 2022 · 15 comments
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@qwerty287
Copy link
Contributor

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

@qwerty287 qwerty287 added type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Apr 4, 2022
@lunny
Copy link
Member

lunny commented Apr 4, 2022

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

@qwerty287
Copy link
Contributor Author

Actually none, but

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

@6543
Copy link
Member

6543 commented Apr 4, 2022

@6543
Copy link
Member

6543 commented Apr 4, 2022

aGit Workflow is already implemented

@qwerty287
Copy link
Contributor Author

@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
Copy link
Member

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

@tastytea
Copy link

tastytea commented 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.

@qwerty287
Copy link
Contributor Author

@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
Copy link
Member

lunny commented 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.

@qwerty287
Copy link
Contributor Author

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
Copy link
Member

6543 commented 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 6543 closed this as completed Apr 5, 2022
@6543
Copy link
Member

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

@luwol03
Copy link

luwol03 commented 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.

@6543
Copy link
Member

6543 commented 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 / ...

@luwol03
Copy link

luwol03 commented Apr 5, 2022

Created one to continue discussion there: #19327

@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

5 participants