Skip to content

Conversation

@amacarthur
Copy link
Contributor

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.

@dzaporozhets
Copy link
Contributor

Thank you for pull request.

But there are few problems with it:

  1. All repos logic should be implement with gitlab-shell.
    In this case we can be sure all hooks are added to repository.
    Basically current implementation does not work correctly since repo miss update hook
  2. This feature has long discussions and we are not sure we should implement it at all. Fork is almost useless in private development. At least I think so

@amacarthur
Copy link
Contributor Author

  1. I will update to work with gitlab-shell, and copy the update hook
  2. I think this depends on just how large a user base is being hosted in "private development". In a large company of several thousand developers, it is not always feasible to have all interested developers being team members. Wouldn't we want to allow someone to simply fork a code base and experiment without having to get access to the project?

@dzaporozhets
Copy link
Contributor

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

@vsizov
Copy link
Contributor

vsizov commented Mar 6, 2013

@randx +1
You can use protected branches. So you can "experiment" so much as you want.

@raphendyr
Copy link
Contributor

For study use forks might be good. Teacher sets up course template repo /course_code/exercise.git and tells students to fork it and then add read access for the teachers.

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.

@amacarthur
Copy link
Contributor Author

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

@mchatterley
Copy link

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?

@dzaporozhets
Copy link
Contributor

Arguing does not makes too much sense since different teams use different workflow.
Simply I dont want to implement forks now.
But I'll definitely accept a contribution if:

  • it will handle forking with gitlab-shell. So forked repo should have all hooks and be valid
  • it will respect current security level.
  • it will be tested and quality so I dont spend a lot of time on it

@amacarthur thank you again for submited PR. But we can not accept this implementation

@amacarthur
Copy link
Contributor Author

Thanks @randx . Sounds reasonable. I will update the pull request with the changes you require.

@drf
Copy link

drf commented Mar 6, 2013

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

@hiroponz
Copy link
Contributor

hiroponz commented Mar 7, 2013

I think that the fork feature is less-than-well-thought-out yet.

  1. It may need a large disk space. When a large repo is forked by many users, the system may crash by the disk shortage. It may need to control the disk usages.
  2. How about LDAP username? The username can't control from gitlab, so it may cuause a routing problem. It may need to validate the username to allow to fork.

Sorry, my english may be mistaken.

@drf
Copy link

drf commented Mar 7, 2013

  1. This is no issue as personal projects are still limited. One can use the same argument when talking about importing repos from github or other sources. Disk control would be nice but it's surely not a blocker for this compared to what's already there.
  2. I didn't really get this. Once the user is authenticated Gitlab simply relies on its internal username, which is synced with LDAP only on user creation (and can still be changed). And even besides that, I don't understand why routing would be an issue...

@amacarthur
Copy link
Contributor Author

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

@hiroponz
Copy link
Contributor

hiroponz commented Mar 7, 2013

@drf thanks for reply.

  1. I think that forking project is much easier than importing repos for users. So I fear that users would consume the server storage unconsciously.
  2. Sorry, the problem is not LDAP, but namespace(= user name) that contains non-ascii chars. Non-ascii chars in url often causes routing problem.

@drf
Copy link

drf commented Mar 7, 2013

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

@hiroponz
Copy link
Contributor

hiroponz commented Mar 8, 2013

@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.
It should be fixed before the fork feature would be released, because a forking project needs a personal namespace necessarily.

@randx @vsizov How do you think about this?

@kirantpatil
Copy link

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,
Kiran.

@dzaporozhets
Copy link
Contributor

I close this one. @amacarthur please open new one when ready

@amacarthur amacarthur mentioned this pull request Mar 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

8 participants