Since it's Valentines Day, I'll squee about something I love. Github. Oh I loves it so hard. Hopefully this love will stand the test of time.
For years now I've wanted to replace mailing patches around with a version control centric system. I drop patches on the floor all the time, they get lost in my inbox or in the ticket queue. And that sucks, because people who actually write code are really valuable.
To fix this, I want a system that let anyone make their own branches, which they own, for each task they want to do. They could do easy updates from trunk, and when they're ready, they'd ping the project integrator to evaluate the change and pull it in.
SVK came close to this potential, with it's easy pushing and pulling and SVN-like syntax, but I never came around to making the associated tools and web site. Now, github has implemented this. This is why I've moved Test::More to github and why more will be following.
Instead of branching, you fork the whole project. Git makes this cheap. You have total control over that fork, which is good because I'm a terrible bottleneck. When your ready, you issue a "pull request" which pokes me to look at your changes and integrate them. Even better, there is a fork queue where you can see what changes are pending. Then a few clickies on web forms and the patches are integrated. It's a whole lot easier than the normal git pull process (see step 5). Github's integration process could provide a little more information about the merge, but I'm sure that will come.
Today I integrated a patch before it was even submitted!
Heart.
Do you plan to move EU::MM to Github?
Re:EU::MM
schwern on 2009-02-15T01:09:02
You're about the fifth person to ask that. Seems people really want to mess with MakeMaker.
:) Most likely. There's talk of instead of keeping a separate repository, for very core-centric modules like MakeMaker and ExtUtils::Install to instead just fork off the perl repository on github. This will make p5p and CPAN coordination much easier.
One showstopper, now resolved, was that the perl repo is rather large and forking it would eat up a big chunk of a free account's quota. Turns out forking is about 15 megs of the 300 meg quota, so that's not a problem.
Second is how to make the CPAN distribution and the core layout work together. It might be as simple as building up the CPAN layout using symlinks and only have it exist in my fork.
So I've made a fork for MakeMaker and will start playing with it.
Re:EU::MM
educated_foo on 2009-02-16T01:42:50
One showstopper, now resolved, was that the perl repo is rather large and forking it would eat up a big chunk of a free account's quota.
Why not just use repo.or.cz, which provides actually-free Git hosting for Free projects?
Re:EU::MM
schwern on 2009-02-16T20:01:07
Because I like GitHub, I like the people, they've been nice to Perl (they approached us to mirror in the Perl repo) and it's a whole lot more than just a place to host my git repositories. I don't want to knock repo.or.cz, they're doing a great service, but if you think J Random Server running the stock git server is a replacement for GitHub, you really haven't looked at GitHub.
[Incoming rant. Not necessarily at you, but you triggered a soft spot. And I'm sorry for ragging on repo.or.cz, they're doing a great service, but they serve a perfect contrast for the purposes of this rant.]
But you were implying that "actually free" is implicitly better than "free for Open Source, pay for the rest of you" and that's the major feature upon which one should select their hosting. I call bullshit. The hardware costs money. The bandwidth costs money. The power to run it all costs money. Running, maintaining and improving it all costs time (which is money). So unless you're independently wealthy or supported by some other institution (which makes money) you're a bit fat hypocrite to think that your hosting should be "actually-free" and that there's something wrong with trying to pay the bills. repo.or.cz is hosted by a Czech company who charges customers to make money to support those "actually free" repositories.
And the "actually free" site isn't. They restrict themselves to Open Source projects only. Their default quota is 100 megs, even smaller than GitHub's 300 megs. So I really don't see the advantage even on the "it's more free" front.
And no backups?!! Gah! Don't give me this BS about git providing it's own backups. I want to know my data is going to be there.
Which brings us back to the advantage of a business funded, free-for-Open-Source service. Paying customers demand, and can pay for, a higher quality of service, particularly reliability. Because software scales so well, it's cheap for GitHub to provide those features that businesses pay for (like backups and reliable uptime) to all the Open Source projects.
And while businesses go under, just as often J Random Guy loses interest. Or they lose their benevolent funding.
Finally, it's important to distinguish between projects funding themselves using paid business accounts (GitHub) and businesses taking advantage of Open Source (I'm going to use a caricature of Apple as the straw man here). GitHub is part of the community. Apple makes use of the community. Don't lump them together. The GitHub folks are nice guys.
[End of rant]
Re:EU::MM
jdavidb on 2009-03-31T18:27:07
It seems to me that a zealous Open Source/Free Software advocate would be glad to see discrimination against proprietary software packages, forcing their producers to pay while Open Source folks go free.
But what do I know?
Re:EU::MM
Aristotle on 2009-02-16T20:04:49
How about “Because it’s missing all of the features that Michael is squeeing about in his post”?
It certainly helps resolve the problem of patches versus giving commit to trunk.
Well, the way they apply patches sucks.
Apparently just doing a simple fast forward merge is not cool enough, so a cherry pick with a signoff is done instead, meaning that your contributer now has to do a git reset --hard or they will run git pull and accidentally create a merge commit merging their changes with... you guessed it, their changes. Great =P
Please just use git remote add foo git://github.com/foo/project.git and then git remote update and git merge. It's just as easy, and actually works.
Re:Github's fork queue sucks
schwern on 2009-05-03T19:40:59
You seem to be assuming you're always going to be pulling in all their changes, in which case a merge might be better, but otherwise a cherry-pick and sign off is correct. They could detect that you're asking for all changes and do a merge, sounds like simple a feature request to me. And hey, here it is.
Worrying about the fiddly technical details of how they do their merge, fiddly technical details which could change tomorrow, fiddly technical details which really don't have that big an impact, is missing the point. The FQ lets you see, at a glance, what's going on in ALL your forks. This is the essential bit. It cuts out about five steps from sending and applying a patch. It is glorious.
Re:Github's fork queue sucks
nothingmuch on 2009-05-03T20:21:22
fiddly technical details is an understatement. anybody who wants to contribute a simple patch will need to learn how to use one of git's scariest commands the next time they try to contribute.
At least in my experience cherry picks are definitely *not* the common behavior.
Thus only real use the fork queue has is to list the pending commits, and for that git log --decorate --all is at least IMHO more useful (well, actually I use gitx for that, but whatever).
Re:Github's fork queue sucks
schwern on 2009-05-03T20:55:34
You're the first I've heard mention this problem, and I cherry pick all the time. *shrug*
