[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Move to git?

Hi Folks
I have been using git for a few sub-projects, like the PHP classes as an excuse to learn it. I can see why some people like git. It does some things quite well.
Interesting that you didn't already take the plunge and switch if you already tried it?
Just as a datapoint, for me using it briefly was a complete epiphany on how I could change (improve) my development cycle. I love that a DVCS basically makes "commits" the unit of work and that these basically become "portable". So I love that I can create branches so easily, fiddle around with something, create some changes, and then basically commit a "feature branch". I can then easily pull several features from different branches into some master branch. Especially when it's multiple developers independently working on these individual feature branches it feels like magic that you can still quite easily pull all the features back upstream!
The second big benefit that *I* found was that the quality of my commits increased. Arguably this isn't a git feature and works just as well if you use svn, however, I think because I now get benefit from having the "git log" tell a story, instead I now commit lots of small individual commits rather than with svn where I tended to just "checkpoint" the code every so often... I use the command line client and I find it's very easy to tease apart even a large chunk of work into individual changes...
Mercurial, maybe but I haven't learned it yet and don't really want to take the time to yet. However so far what I have heard is that it does offer some of the revision control system guarantees notably missing from git.
I'm not sure about "guarantees", but yes, mercurial is considered to be "opinionated" and directs workflow quite a bit, whereas Git is more like a toolkit that allows you to generate your own workflow, but throws more of that back on the owner to decide. I don't use mercurial, but the arguments in favour sound interesting. From what I can see users tend to arrive at one of git/hg/bzr and it's a life changing event and at that point they tend to get stuck into whatever they first tried (or works best initially). As such seems like personal choice to a large extent, but they are all excellent and very powerful tools, I don't think the exact choice is all that important
Thing you have to remember about git is it isn't a revision control system, but rather a change management toolkit and it doesn't offer the basic guarantees of a revision control system by default. For example it is possible to overwrite past changes/revisions using git. Of course you can build a solution that does offer these guarantees but the more complicated you make it the harder it will be for cross-platform development to happen,
Hmm, I suspect you have some point you are trying to make here, but I'm afraid it's not clear to me, and whilst I probably misunderstand, I would disagree with the points above?
Fundamentally both Git and SVN are pointed at some directory and they simply checkpoint the files in those directories whenever you push a button. The difference between them is really only about how flexible they are with change and branch management (IMHO).
So for example if you have two copies of an svn repo, with changes in both, then my svn skills would not easily merge the two sets of changes. However, such a task is very straight forward (for me) in git.
Creating feature branches and managing release branches is similarly straightforward in git, but I'm quite unsure about a good process to emulate the same in svn (eg I have some feature that I make available as a patch to kernels 3.1-6, ie as 6 separate branches. I fix some bug in the core feature and I want to pull that change to each of the 6 branches and at the same time update the patch to apply cleanly to the latest version of each kernel version - this is fairly trivial in git, but I'm unsure of an efficient process in svn)
With regards to overwriting past changes, this is trivially prevented and most significant public repos have that enforced. Even the defaults cause pushing changes to history to require additional options and some deeper knowledge of git to make it happen. So overwriting history is simply an option that you can enable on your public repo, but there is no real challenge to turning it off and enforcing it (because it's server side, the choice of client makes no difference)
So I don't see any complication with preventing history revision, nor anything which complicates cross platform development. I believe it *does* offer the basic guarantees of a revision control system and can be considered a superset of svn... (By all means lets argue any specific weaknesses, but lets not get into a flame war on A vs B, there are certainly pros and conns, I just wanted to tackle that all of the features of SVN can be achieved with git without any great effort, IMHO)
Ideally we'd add shell scripts and .bat files that would allow people to run identical series of commands to do things like submit changes back etc. that would run on all platforms. We already have some unaddressed issues with OSX and shell scripts. I don't really want to multiply these.
Again, probably you have specific things in mind, but I'm unsure what you might be thinking of? I can't think of any significant git hosted projects which use any form of bat or shell scripts to assist with commits? In fact I can't think of a particular reason to use shell scripts? (git pull, git checkout, git push...)
Perhaps you could describe why shell scripts are needed? Perhaps git would actually make these shell scripts disappear? Note that with git it's normal and quite straightforward to install hooks both client and server side into the repository itself that run every time you do certain tasks. This for example can be used to refuse to allow someone to commit code which doesn't say match certain style guidelines or pass some smoketest or say decline changes to history in certain branches, or send emails on commit, etc. 
    http://git-scm.com/book/en/Customizing-Git-Git-Hooks
In this scenario we would see git for now largely as a merge-management tool for general use. However at present, I think that a lot of things (including review of commits) will be made harder or at least more inconvenient, rather than easier by a move to git. I am also somewhat concerned about necessitating more complexity regarding processes around the project.
Ultimately the main developers will decide what makes things harder or easier, but if I could draw your attention to a huge groundswell of people who tried git (or HG/BZR) and decided that they made things easier? I'm not claiming to get a vote, but definitely for me git is vastly easier to manage commits
Example of practical ways I know use commits is that I regularly examine individual code changes in the commit history in github and learn from them. eg, I recently synced to twitter bootstrap and formatting broke in Firefox, in a few minutes I could track down the change which caused it, add a comment, raise an issue and my own fork continues to track master with a simple "git pull" yet it's got that change reverted: 
https://github.com/twitter/bootstrap/commit/fa38ab573b99e6e65184626b37867f50802b228f#less/mixins.less
Encouraging forks to stay on a single server is also interesting, eg in the case of bitbucket/github, etc. I often find it interesting to be able to go code spelunking to grab bug fixes and features: 
    https://github.com/ewildgoose/ym4r_gm/network
Anyway, these are all reasons why *I* very much value git vs svn, however, I do respectfully realise that this decision needs to be driven by the main developers. Hopefully the above gives you a reason to at least investigate the option and an example of someone enthusiastic who believes there is value there if you choose to investigate further. A few other opinions (chosen because they are hopefully fairly down the line and not too emotionally biased...): 

http://kolab.org/blog/adams/2012/08/16/cyrus-imap-what-happened-when-they-switched-git
http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
http://www.gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/
http://www.heartmindcode.com/blog/2011/03/svn-users-why-you-should-switch-to-git/
http://blog.geoserver.org/2012/07/09/geoserver-has-moved-to-github/


Cheers

Ed W