<div dir="ltr">After a few years of git use, I have no desire ever switching back to Subversion, and I also have little desire to switch to something else given that I've got myself used to how git sucks. I felt the same lack of desire when I switched from CVS to Subversion, from RCS to CVS and from plain files.  Source code control is fundamental to the daily workflow of most programmers, making any changes in how it works to look painful and have the obvious disadvantage of slowing them down every single day, at least in the beginning.<div><br></div><div>That said, I do think that git is much better than Subversion for its easy branching - Seeing Gary's "heads-up" messages when he starts some larger activity on the trunk is, while somewhat entertaining and "community building", also reminding me of days way back in the past, when everybody contended for the scarce disk space and servers.  Nowadays, making a large chunk of work consisting of a multi-day effort available to the public is typically an atomic operation, where the programmer merges the branch back to the main line.  From a technical perspective, I do believe that such an approach is better than emails telling people not to pull from upstream because upstream may be unstable.</div><div><br></div><div>GitHub, on the other hand, is less of a panacea.  It is as centralized a system as SourceForge, and it shares the same negative aspects (like, in our present days, frequent Denial of Service Attacks causing a "small percentage of repositories" to become unavailable at inconvenient points in time [*]).  It is a great communication platform, though, and being able to submit an easy-to-merge fix with a bug report is lowering the bar for people contributing to an open source project quite a bit.<br><br>The centralized nature of GitHub does not affect the decentralized nature of git repositories, though, so using GitHub to facilitate communication is does not seem like a bad idea for an open source project.</div><div><br></div><div>The real issue with migrating or augmenting Clozure CL with git or GitHub is that CCL uses Subversion's remotes mechanism as a binary distribution mechanism.  The build system assumes a certain directory layout which is a mixture of an architecture specific checkout of a bunch of binaries and with several subdirectories being checkouts of the source code.  Any attempt to make different source code control systems useable in addition or as replacement to Subversion will need to consider how the build setup works, and also provide a way to bootstrap CCL from boot binaries and source code.</div><div><br></div><div>This is certainly something that sounds doable, but it is significant work given that multiple platforms (Windows among them) need to be considered.  I would suggest that anyone who suggests moving CCL to git would be a good idea to consider what this would actually entail, or better yet, do the work and show us how things work with git.</div><div><br></div><div>Just saying.</div><div>-Hans</div><div><br></div><div>[*] Unfortunately, that "small percentage of repositories" almost always included those repositories that I needed to work with, making me move away from <a href="http://github.com">github.com</a> for all my commercial work.</div></div>