Some thoughts on Version Control

While coding for quite a long time now, it is very natural for me to use Version Control systems every day. I must say that I did quite catch the hype on git and wanted to try it right away. Although I do not come from the ruby world and am more a PHP guy, I gave git a go.

Making my first repository on github an commiting some changes was really easy, no hassle and really fast response times. Whend looking at the subversion timeline it takes me almost 10-15 sec before I can see any result, when using git, even cloning is faster than that.

So I decided to use git for some small projects on my own, locally on my OS X box and shared public on github. I was fascinated by the easy branching and merging, something I always missed when using subversion, cause branching in subversion is like driving a car from the 60’s.

It works, but you never know when it will break. Only one thing is for sure … it WILL break ;).

But one thing were git loses its natural strength is when it should do what it was supposed to do, Distributed Version Control. I would have never thought that it could be so hard to maintain a git repository between two persons working on one codebase. I was working with a windows guy, and we had really some big troubles with the line endings. It took us nearly 10 commits, till the line-breaks were all set to LF.

Depending on how many persons will work on your repo, you will never fully get rid of em, and the worst of all are the ‘diffs’ you see in your

git log

Cause it is the whole file twice, really annoying.

But nevertheless, once you finally got it working it always produced trouble, when doing a push or a pull, cause the merges always ended in a disaster, as git’s merge strategy sometimes just had overwritten some fresh changes, or just aborted and then refused to continue.

Since this did not work out, but I wouldn’t wanna lose the really good merge feature, I tried git-svn. But just the first start was just a shot in the knee, here is what I did:

I cloned the SVN repo from remote, and git automatically fetched all SVN branches correctly and pulled them to local lightweight branches, so easy switching was possible.

Directly after cloning the repository, git complained, that there were some CRLF errors. Ok no worrries, just one:

git commit -a -m "Fixes the CRLF to LF" And you’re good. Then my buddy commited some stuff, and I wanted to pull the changes, so I typed:

git svn rebase
First, rewinding head to replay your work on top of it...

Ahh thank you git, you recognized I had changes (the LF stuff) in my file that had not been in the remote-master

Falling back to patching base and 3-way merge... error: Your local changes to 'public/js/form/jquery.validationEngine.1.6.2.js' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Failed to merge in the changes. Hooo, quite an error here, ok he aborted the merge, what to do now?

Actually I do not even understand why this problem occurs, cause my repo was rewinded, but anyway, lets have look on the file, cause there are supposingly some merge markers in it and I will just resolve the conflict …

mate public/js/form/jquery.validationEngine.1.6.2.jsHmm, no merge markers here, so I will follow git’s advice

Please, commit your changes or stash them before you can merge. When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". So what I do is:

git commit -a -m "Added the merge" git rebase --continueAnd what I get is:

No changes - did you forget to use 'git add'?What? Ok, I give it a go

git add .And what I get is just a newline

\nOk, I tried some more commands but didn’t get the solution, so I recloned the repo and made:

git svn dcommitdirectly after fixing the LF thing, but then other errors occured when maing my next commit. Believe this could on for ages … I tried it back and forth, and I am 100% sure there is a solution to all of these problems, but what is the price I have to pay for this? Some git commands are so abnormal, I just can’t quite remember and end up in beeing a man-page reader instead of a coder.

Working with git makes me very unproductive and gives me headaches, so I finally surrendered and switched back to SVN. Just one note here, do not even think of using git-svn, it is even worse than git alone when you are working with more than one person.

When I heard the talk of Linus Torvalds on Google, he always stated that you should use the best tool for the job. And quite frankly Torvalds, this cant seriously be the best tool for the job.

Leave a Reply