Below is what I consider to be the disadvantages of Git – when compared to subversion. I should point out that these are just my niggles with git – I still prefer it over subversion because stashing is cool, and there is always less merging when using Git.
Git uses “hashes” which are completely unreadable for humans – it makes revision tracking difficult to process mentally. For git fan-boys, don’t try to deny to this argument, it just wont work; instead hang your head in shame, or just change the subject, comebacks to this one won’t stick.
This has got to be the worst part of git. I consider this a deal-breaker for many projects – some projects shouldn’t use Git because of this one single feature.
Git does not allow partial checkouts of repositories, so either you live with entire repository checkouts, or use “submodules” as a bad excuse for partial checkouts. Not having partial checkouts is very annoying, and using submodules to facilitate it is like using a machete to cut your fingernails – good luck with that!
Why is git so verbose?
Working Copy Status
When I do “svn status” in subversion – I get a list of files and their status’ along the left. Parsing this information at a glance is easy – it follows the same principles as “ls -l” – convention is good – I’m already used to it, I don’t have to learn something new.
When nothing has changed in my working copy and I do “svn status”, I get nothing. Sweet!
Try the same in git and I get:
# On branch master
nothing to commit (working directory clean)
Why do I have to mentally parse process 2 lines and 9 words to find out NOTHING has changed? Surely this is the definition of poor communication?
Why do I have to “add” files that have changed, before I commit them. They are already in the repos – if I didn’t want them version controlled and committed on change, I wouldn’t have added them to the repository in the first place. No, I don’t want to use the -a flag – I just want the commit command to make sense.