I have to admit that I haven't played around with Git much beyond familiarising myself with the commands enough to get by with the various projects I know that are using it
( Read more... )
I think this is a consequence of an inactive maintainer. In the absence of github it'd be patches on mailing lists and web servers, like the pre-history of Apache.
But I don't necessarily agree with your conclusion though - in my experience, in the face of an inactive maintainer then people tend to either start really hassling the maintainer until they hand over the reigns or they start an new 'definitive' fork.
The essence, I think, is that when it's easier to keep your code in a silo than it is to push back to trunk (or establish a new trunk) then people will take the patch of least resistance. Which is good for them but bad for the wider community.
...
I think I just argued for enforced code communism.
I suppose I agree with you to some extent. However another thing that might happen in the absence of github is a complete lack of published patches. A lot of expedient hacks to get something working are not good enough to be published "properly". Perhaps the zoo on github indicates that people are less embarrassed, or perhaps the reduced impedance means they can make a patch available without "publishing" it.
+1. I always recommend everyone to patch Remedie (on github) to NOT fork and use git format-patch to send to gist. That way I don't need to care about the forked repositories anymore and lots of wasteful merges there.
The distributed nature of (git|hg|bzr) makes the chaos possible and even a bit more likely but, at least with git, it makes the chaos easier to calm.
Speculate for a moment that you've got a fancy new checkout of Thinger from Thinger's Official Subversion and you find an edge case that needs immediate fixing for your project to continue. You fix it. To share the love, you're stuck with a single patch blasted to a mailing list because you had to check it out over HTTP and you can't commit back.
Speculate now that Thinger is using Git (not necessarily GitHub but they make it even easier). You've got a copy of all of your changes, neatly annotated with commit messages that the Thinger maintainers can pull into a branch on their copy, examine and merge. Git makes takes the guesswork out of the patch-and-pray-it-works workflow.
Oh, I get all the advantages of Git and the work flow you're describing is largely how I use SVK.
My problem is that whilst Git makes that workflow possible if people stop doing the final step of merging the branch back into trunk then we end up with little siloed versions of apps.
So, for example, I branch Thinger and fix a few bugs and you branch it and add WeebleFlitzing support and neither of use push our changes back and since the maintainer doesn't know about us he doesn't pull them back in.
Now J Random Person comes by and wants both my bug fixes and your WeebleFlitzing support and then he has to go to the effort of doing the merge just like in the old days of NCSA httpd.
I admit that's a worst case scenario I and really hoped that I was just being curmudgeonly but that sort of behaviour has already started to happen which is sooner than even I suspected.
The odd thing is that mostly I've seen it in the Ruby community. I don't know quite what to make of that.
(I hope the friendly people at GitHub see this thread.)
My point above was that Git makes it easy. You've got me though, Git doesn't make it *happen*. GitHub may be able to help here. It'd be fun to see a "community" version of every repo that's been forked. This version would automatically pull from all of the forks. That puts a lot of faith in the patches made by the forkers but the middle ground of notifying the originator when any commits are made to forks is a bit tedious and brings us back to NCSA-syndrome.
Stepping back for a moment, I don't think it's possible to make any of this effortless without completely trusting forkers-at-large. So Git simply making it easier to merge might be enough of a win to call it a day.
i had received patches from someone who forked my svn project into github. i appreciate getting patches (i love it really), but his fork was behind from my mainline and required a lot of hand holding to integrate his patches.
really frustrating, even for my really small project.
either way, AFAIK git makes it easy to send patches back up-stream to mainline; maybe its github that needs to work on facilitating this?
one of my projects at work uses it and the distributed nature has been a god-send.
Comments 12
its bad enough that ruby people have decided that rubyforge is no longer the main repository for gems.
Reply
Reply
But I don't necessarily agree with your conclusion though - in my experience, in the face of an inactive maintainer then people tend to either start really hassling the maintainer until they hand over the reigns or they start an new 'definitive' fork.
The essence, I think, is that when it's easier to keep your code in a silo than it is to push back to trunk (or establish a new trunk) then people will take the patch of least resistance. Which is good for them but bad for the wider community.
...
I think I just argued for enforced code communism.
Reply
Reply
IDEAL GITHUB WORKFLOW:
1. Find bug
2. Find primary repository
3. FORK
4. Patch on fork
5. Push at maintainer
6. Maintainer accepts patches
7. YOU DELETE YOUR FORK
Have you noticed how easy it is to hit the "Fork" button? Why isn't there a just as easy to get at "Delete" button for forked projects?
In an ideal world, I'd like to have the option "autodelete this fork when it's integrated upstream".
Reply
Reply
Speculate for a moment that you've got a fancy new checkout of Thinger from Thinger's Official Subversion and you find an edge case that needs immediate fixing for your project to continue. You fix it. To share the love, you're stuck with a single patch blasted to a mailing list because you had to check it out over HTTP and you can't commit back.
Speculate now that Thinger is using Git (not necessarily GitHub but they make it even easier). You've got a copy of all of your changes, neatly annotated with commit messages that the Thinger maintainers can pull into a branch on their copy, examine and merge. Git makes takes the guesswork out of the patch-and-pray-it-works workflow.
Reply
My problem is that whilst Git makes that workflow possible if people stop doing the final step of merging the branch back into trunk then we end up with little siloed versions of apps.
So, for example, I branch Thinger and fix a few bugs and you branch it and add WeebleFlitzing support and neither of use push our changes back and since the maintainer doesn't know about us he doesn't pull them back in.
Now J Random Person comes by and wants both my bug fixes and your WeebleFlitzing support and then he has to go to the effort of doing the merge just like in the old days of NCSA httpd.
I admit that's a worst case scenario I and really hoped that I was just being curmudgeonly but that sort of behaviour has already started to happen which is sooner than even I suspected.
The odd thing is that mostly I've seen it in the Ruby community. I don't know quite what to make of that.
Reply
The odd thing is that mostly I’ve seen it in the Ruby community.
“I just put it in vendor.”
Reply
My point above was that Git makes it easy. You've got me though, Git doesn't make it *happen*. GitHub may be able to help here. It'd be fun to see a "community" version of every repo that's been forked. This version would automatically pull from all of the forks. That puts a lot of faith in the patches made by the forkers but the middle ground of notifying the originator when any commits are made to forks is a bit tedious and brings us back to NCSA-syndrome.
Stepping back for a moment, I don't think it's possible to make any of this effortless without completely trusting forkers-at-large. So Git simply making it easier to merge might be enough of a win to call it a day.
Reply
i had received patches from someone who forked my svn project into github. i appreciate getting patches (i love it really), but his fork was behind from my mainline and required a lot of hand holding to integrate his patches.
really frustrating, even for my really small project.
either way, AFAIK git makes it easy to send patches back up-stream to mainline; maybe its github that needs to work on facilitating this?
one of my projects at work uses it and the distributed nature has been a god-send.
Reply
Leave a comment