-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Adding button to Fork projects into personal namespace #3145
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
Conversation
|
Thank you for pull request. But there are few problems with it:
|
|
|
You cannot access code unless you are in project team. Or unless project is public. So forks will work only in case project is public |
|
@randx +1 |
|
For study use forks might be good. Teacher sets up course template repo For above use it would be handy to add permissions into fork when fork is created. Eq. Orginal repo users would get read access to fork. This also might be needed for merging I ques (or not). Any case it would be logical as repos are private. Of course forker should be able to not allow read access for orginal developers. |
|
@randx - We are planning on having an "all-users" team which each project will default to give Reporter access to. This plus the ability to Fork emulates a GitHub style community so that a user can easily innovate on someone else's code without needing push access to the original repo. @vsizov - If you don't allow people to easily experiment in their own sandbox, then you introduce an unnecessary barrier where they need to ask for push access to the repo - presuming they can even discover it exists. In our situation we have an existing GtiHub Enterprise install which we want to migrate to GitLab. Since we have a large user base, GitHub style development has been very well received, allowing people to discover and innovate on one another's code. We want to preserve as much of that style as possible as we believe it encourages innovation and collaboration. Is the usage I am describing really fundamentally against the philosophy of GitLab? |
|
Allowing forking is very useful for letting people try things out in their own sandboxes more quickly because in their own fork they don't have to conform to the original project's conventions. They can take shortcuts to try something out without worrying about being criticized for making a mess in someone else's project. So it's an ideal feature to encourage prototyping. In our environment it is a feature that is used very heavily. Larger companies will also often have a mix of public and private projects. Some projects will be required to be kept private for security and secrecy reasons but the more open things are for everything else, the easier it is to collaborate and innovate. @randx this feature would only be useful for internally public projects as you suggested but is there any reason not to implement it if it will benefit some people that would like to use this development model? Personally I think it makes your product more flexible and it would likely make it much easier for other large companies to switch to your product as well. Would it make sense to make this a feature that you could turn on or off? |
|
Arguing does not makes too much sense since different teams use different workflow.
@amacarthur thank you again for submited PR. But we can not accept this implementation |
|
Thanks @randx . Sounds reasonable. I will update the pull request with the changes you require. |
|
I really like this feature and I can see a huge added value for the workflow of my team. On the other hand, one thing I'd love to see is the capability of making MR from a fork to the "master" repository a-la-github. In addition, the use case described by @amacarthur becomes even more interesting when Teams are synced with LDAP (I'm trying to cook up a patch for that). |
|
I think that the fork feature is less-than-well-thought-out yet.
Sorry, my english may be mistaken. |
|
|
@randx - Could you clarify what you mean by "it will respect current security level."? Are you thinking that the Teams would be included in the fork? I was thinking that the fork would essentially be private to the forker and not bring any Team assignment with it. |
|
@drf thanks for reply.
|
|
@hiroponz : I still personally do not agree with the rationale in 1, but I can understand your reasonings. About 2 - if so, this problem already exists as it's already possible to create personal projects in a personal namespace (username). Again, doesn't look like a blocker as it doesn't introduce any changes compared to the current features/behavior. |
|
@drf I agree with the fork feature, but I have pointed potential problems to improve fork feature. About 2 - there seems to be some potential bugs in a personal namespace in current master branch, because most users use only a global namespace. Non-ascii user name is one of them. |
|
Hi @amacarthur, If fork shares the same repo then it does not have data duplication issue, otherwise fork will be a separate repo and it consumes twice the disk space (data duplication issue). Github used "git alternates" command to mitigate data duplication issue. Please have a look at this presentation, http://zachholman.com/talk/how-to-build-a-github/. Thanks, |
|
I close this one. @amacarthur please open new one when ready |
This adds a "Fork" button on the Project show page. When clicked, a clone of the new project is created in the namespace of the currently logged in user.