Gitlab should be able to federate different instances
Created by: duritong
While gitlab lets us host our own cool git hosting service, we cannot participate in a truly distributed/federated (read git-like) manner.
If a project A ist hosted on gitlab.example1.com a user can only open issues by having an account on gitlab.example1.com, although this user might have an own gitlab instance on gitlab.example2.com.
The same goes for pull requests, forking and so on. It's all only possible within a single gitlab instance and while a user is not anymore depending on a single hoster, she might still not be able to host her code (read her forks) on her own server.
Also if gitlab becomes more widespread contributing to different FOSS-projects might become cumbersome, as users will need a seperate account on all the different installations.
Therefore gitlab should look for ways to federate different installation. That would mean (not a complete list):
- A user can login with a gitlab account on gitlab.example2.com also on gitlab.example1.com, she would enter her credentials only on gitlab.example2.com.
- A user can open issues/comment/edit the wiki/... on gitlab.example1.com with her account on gitlab.example2.com
- A user should be able to fork repositories onto her own gitlab installation
- A user should be able to send pull requests from her own gitlab installation
This would allow a collaboration over the web in a truly git-manner.
Activity
Created by: mcfedr
These are some interesting ideas, I like what you are suggesting.
It seems that the first two points could be solved using OAuth - If a gitlab server allows logins using OAuth and is also a provider, you can then have an account on one host, and use it to authenticate on others.
To fork a repo onto your own installation would also be a neat feature, It could be made more generic, so when you create a new repo you can give a git url to fork it from, this would let you create forks of projects hosted on any git server, not just gitlab - maybe even from lesser systems via git-svn etc.
In theory having forked a remote project, you can also push to it - creating a pull request... I think thats the hardest part.
By Administrator on 2012-08-16T14:30:11 (imported from GitLab project)
By Administrator on 2012-08-16T14:30:11 (imported from GitLab)
Created by: dlaxar
Hi!
I'm not an active GitLab developer, but I'm trying to become one. When reading this idea I fist thought "Uh, cool" but then I realised what that'd mean.
Many companies use GitLab for their repos, which would mean, that if you have an account on a public GitLab server, you can log in at the companies GitLab instance. Uhm.... not so good!?! However this can actually be done, and is done. Configure an LDAP authentication on both instances, and you can log in on both. Or OAuth, if this can be controlled by the server admin...
I don't see the point in cross-forking. Again, you need to have an account to submit a pull request after forking and editing so the above applies.
Anyways, these are some very nice thoughts and especially OAuth seems to be a very nice idea.
By Administrator on 2012-08-16T15:26:57 (imported from GitLab project)
By Administrator on 2012-08-16T15:26:57 (imported from GitLab)
Created by: duritong
Many companies use GitLab for their repos, which would mean, that if you have an account on a public GitLab server, you can log in at the companies GitLab instance. Uhm.... not so good!?!
It should definitely be possible to turn off federation for your instance.
By Administrator on 2012-08-16T18:50:23 (imported from GitLab project)
By Administrator on 2012-08-16T18:50:23 (imported from GitLab)
Created by: mcfedr
It should definitely be possible to turn off federation for your instance.
clearly
I don't see the point in cross-forking. Again, you need to have an account to submit a pull request after forking and >editing so the above applies.
This seems to me the most useful part of the idea, say you find a interesting project on another public server, or github etc, but your company policy requires you to use in house hosting, you can quickly create a fork, and work on it.
Pull requests are much harder, although maybe gitlab could provide a way to generate a patch from the original that you could then send to the upstream.
By Administrator on 2012-08-16T20:04:00 (imported from GitLab project)
By Administrator on 2012-08-16T20:04:00 (imported from GitLab)
Created by: dlaxar
Hi!
This seems to me the most useful part of the idea, say you find a interesting project on another public server, or github etc, but your company policy requires you to use in house hosting, you can quickly create a fork, and work on it.
Pull requests are much harder, although maybe gitlab could provide a way to generate a patch from the original that you could then send to the upstream.
Seems to be a nice idea.
Please also consider OAuth for authentication. This'd be pretty awesome, if you could log on with Twitter, ..... Maybe when using OAuth as authentication, the data gathered trough this could be used for notifications too? PMs from an official GitLab Twitter account to notify you about changes? Just getting ideas...
By Administrator on 2012-08-17T07:14:41 (imported from GitLab project)
By Administrator on 2012-08-17T07:14:41 (imported from GitLab)
Created by: dlaxar
See https://github.com/gitlabhq/gitlabhq/pull/1248 for the OAuth thing.
By Administrator on 2012-08-18T11:49:29 (imported from GitLab project)
By Administrator on 2012-08-18T11:49:29 (imported from GitLab)
Created by: lloydwatkin
This is something I've been talking about with others recently, although for us OAuth probably isn't how we'd be looking to do it (especially as at a recent conference we were all shouting f**k-oauth with the author of the spec).
Current ideas are that 'gitlab' repo - for example - becomes 'gitlab@git.gitlabhq.com'. I then continue to use my own server at all times (e.g. git.myserver.com) which can proxy through to the remote server e.g. git.gitlabhq.com to get repo details. Users become username@git.myserver.com. For local repos/users we obviously hide away the domain part.
I'm currently evaluating git repo hosting solutions and gitlabhq had this post on federated repo hosting so at least people in this project are starting to think about these things. As much as I love github it's still a silo :)
By Administrator on 2012-11-07T11:39:51 (imported from GitLab project)
By Administrator on 2012-11-07T11:39:51 (imported from GitLab)
Created by: richmidwinter
+1 for federated instances; this is probably most useful for segregated networks where oauth isn't an option, but these should be separate features anyway.
By Administrator on 2012-11-09T19:19:43 (imported from GitLab project)
By Administrator on 2012-11-09T19:19:43 (imported from GitLab)
Created by: slavicv
Little bit of topic question: is Gitlab support concept of
forks? I installed latest stable version and I can't see fork button anywhere. Hate to be newb, but I tried to google this question and it gives me nothing.UPD: oh I see. There is concept of branches with permissions instead of forks
By Administrator on 2012-12-26T16:02:39 (imported from GitLab project)
By Administrator on 2012-12-26T16:02:39 (imported from GitLab)
Created by: senny
Hey guys
Thanks for your interest in GitLab
We don't use the Github issue tracker for feature requests. Please use http://feedback.gitlab.com/ for this purpose. Have a look at the contribution guidelines for more information.
Also don't hesitate to use the support forum if you have further questions.
By Administrator on 2013-04-18T05:22:26 (imported from GitLab project)
By Administrator on 2013-04-18T05:22:26 (imported from GitLab)
Created by: dosire
By Administrator on 2014-06-05T12:37:32 (imported from GitLab project)
By Administrator on 2014-06-05T12:37:32 (imported from GitLab)
