New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Forking and merging over at Sourceforge
This just came down to me in my monthly sourceforge newsletter. I know some folks enjoy this feature over at github. I wish it was a bit more thought out though.
Anyway:
Did you know that new projects (on our Allura platform) let you fork git and mercurial code repositories? We also recently added Merge Requests, so now you can request that your changes be included back into the original repo. You can use forking to maintain a longstanding separate project, or if you just want to submit a small fix, you can create your fork in your "user project". User projects (e.g. /u/johndoe) are places for you to put small things that don't need a whole project. We'd love your help testing these functions, and if you see any errors, please let us know.
Just wanted to mention it. As others have said, github has issues with their setup. Tickets have to go to the original script. Makes things hard to track if you have an issue with the top level script or one of the forks.
Comments
GitHub is still better, since GIT is lightning fast.
shrug Seems more like a persona choice to me. SVN works fine for us. And every Git install I've used can't do simple stuff. Like tracking tickets correctly.
+1
Sourceforge also supports git as a project's source control system, they have for 2-3 years. And github runs an svn read/write gateway, they have for a year and a half now (it started as a (working) April Fool's day joke and then stuck around and was improved on).
I prefer Github too, it has much tighter git integration, and has a code-oriented interface which is much nicer for most of us here (though supposedly less end-user-friendly). SF makes you click through tabs and drop-down menus to get to a page explaining what git is, which finally has the projects' repo URL buried somewhere in all that text. SF's new Allura system looks like it's got a better interface, but I'd assume they're going to run a dual instance of their two hosting platforms for decades unable to commit to switching everyone over to the new one. Github's also not carrying around 12 years of features and code bloat, which probably helps a lot with their service's speed.
But it's not a question of github's git vs. sourceforge's svn. They both do git, they're both just the same once you have the checkout on your system. It's more a question of which proprietary closed network (fork tracking, pull requests, social graph, issue tracking) you want to lock yourself into with your supposedly "distributed" VCS.
BitBucket just added git support, as a first-class citizen. It's not as nice to use as GitHub, and you won't get as many forks of your public projects because there's less people there.
But it allows unlimited private git repos for free, only charging if you want to add additional collaborators to your private repos. GitHub's cheapest plan with private repos is $7/month, and limits you to 5 projects. So it might be worth looking into for the code you don't want to share but want to have hosted/backed-up somewhere. Easier than setting up gitolite on your lowendbox.
BitBucket started as the Mercurial (Hg) equivalent of GitHub, not as big of a userbase, fewer features, but nearly the only choice if you wanted to use hg, so popular with Python developers.