A few week back, I commented some concerns about git causing silos. I think this is a really good post by chris from github, illustrating the advantages of fully distributed development:
It may seem strange, and perhaps even like a lot of work. “Why should I have to check to see which is the most current? In the old model, there’s always a canonical repository.”
In the old model, actionwebservice wouldn’t have made it past 1.2.6. Welcome to distributed version control.
Think remote branch management is a hassle with git? This nice ruby-based helper should sort you out:
$ sudo gem install git_remote_branch
To get a quick explanation of how it works. Or read on at Git Ready
Simon Wistow worries that the distributed nature of git results in fragmented software projects:
That model works well for Linux. Maybe. I’ll presume it does. Git eases the pain points expressed by Andrew Morton, the maintainer of the -mm tree, in this message entitled “This Just Isn’t Working Any More”
In short, it makes siloing easier.
My immediate reaction to reading his post was to think of the old saying ‹‹Guns don’t kill people, people kill people››. In fact, my experiences with forks so far has been two cases of forking repos on github, and doing a pull request to the author when my fixes were fit to be included in the main distribution. In both cases the authors included my changes in their versions.
Just because there exists a lot of works-in-progress doesn’t mean that they represent different authoritative versions of a given module. The situation for the rails OAuth plugin might be a bit muddled, but thanks to github’s excellent network map, it’s easy to track all of the 12 forks on github (substansially less than 27), out of which most seems to have merged into a new mainline.
It is clear that this project suffers from a inactive maintainer, but I believe that Git forks has lowered the barrier to contributing substantially, thus ensuring vitality for open source software projects. Our own Catalyst OAuth support, which resides in SVN is still non-working, despite several promises from people to look into it. These people might have working support in their local applications, but if that is the case, I’m unable to get to them or merge it into the started efforts in Catalyst SVN.
To summarize, Git lowers the barrier to contribution. Building or avoiding silos is up to the software maintainers, and giving support for patched versions is madness any way we look at it. Just the same way as developers are on their own when they use development versions of software, they can’t expect support for forked versions of that software either. If you live on the bleeding edge, you are going to bleed a little.
Great tip about using rebase when you pull from remote to get a cleaner git commit timeline.
Are you trying to sell in git to your colleagues, who are afraid of learning anything new? easy git might be the ticket to convince them. Check out the side-by-side comparison on how to do things in svn and eg