Recently we made the change from SVN to Git for source control in my software development team. We've all been using SVN for years and, while not without its own serious flaws, it works. Managing the archive and access to it is simple, and people can easily check out and contribute with a minimum or effort and training. Yes, they can screw things up, but that's what source control is for...to cover your ass when you've left it hanging out in the wind.
While SVN does require you to pay for the Visual add-in for Visual Studio, that's not so bad. I can see which files I've changed within my dev environment at a glance. Git does not have this feature, but it's not a deal breaker. I can live without this nicety.
Now we have Git in place and holy christ if it isn't the most convoluted and arcane piece of ... software I've ever had the misfortune of using. As someone who grew up with DOS and UNIX command line operating systems, that's saying something.
So I want to check something out from the repository. That's pretty straightforward. I can clone it. Wait "clone"? Yup that's right, not check-out. Now each of my check-ins, er I mean commits is actually local. Strange, but alright...so how do I get my number commits back to the actual server? Now things get tricky.
Different terminology and work flow. That'll take some getting used to, but it's not insurmountable. Or so I think, while trying for the fifth time to get my changes merged into my local test branch, and finally up to the live test spot.
"Rebase, fetch, merge, push, pull, fuck you developer guy!" says Git to me. "You will dance to my tune or ELSE all your hard work will be destroyed. Safe history is all an illusion! Your code will commit, if you've put your dash in the right place. No simple context menus for you! Mwahaha!" So I bow down to the evil overlord who holds sway over my work's safety. I do as he asks and successfully complete the mystical ritual. My code is safe, right? Sure, if no one else has gone in and caused some kind of cluster-fuck with the repo while you were working on your own stuff.
Am I saying Git is a bad thing top to bottom? No I'm not. It's a powerful tool with lots of good features. The main complaint I have is that it takes a concept that is relatively simple at its core and complicates it to the nth degree without giving me, the developer, any real benefits. Managing my code has become a morass of command line incantations, rather than the few clicks and simple visual feedback that it used to be.
Maybe I'm just getting old and can't grasp the 'simple elegance' that is Git. But I doubt it. I've designed user interfaces for dozens of complicated systems, and the implementation, documentation and user friendliness of Git could sure use a few metric tons of improvement. Just because it's made for developers doesn't mean I should have to use a text console and enter lines of nonsense to do my work and commit my code.
A task that should be so simple, shouldn't be so damned difficult to accomplish.
I'm stuck with it now, but every time I have to use it I'll be silently thinking in the back of my mind..."Fuck you Git," praying it doesn't hear me and will actually do what I want.
Please bow your heads and join me in a prayer for the safety of my code.
While SVN does require you to pay for the Visual add-in for Visual Studio, that's not so bad. I can see which files I've changed within my dev environment at a glance. Git does not have this feature, but it's not a deal breaker. I can live without this nicety.
Now we have Git in place and holy christ if it isn't the most convoluted and arcane piece of ... software I've ever had the misfortune of using. As someone who grew up with DOS and UNIX command line operating systems, that's saying something.
So I want to check something out from the repository. That's pretty straightforward. I can clone it. Wait "clone"? Yup that's right, not check-out. Now each of my check-ins, er I mean commits is actually local. Strange, but alright...so how do I get my number commits back to the actual server? Now things get tricky.
Different terminology and work flow. That'll take some getting used to, but it's not insurmountable. Or so I think, while trying for the fifth time to get my changes merged into my local test branch, and finally up to the live test spot.
"Rebase, fetch, merge, push, pull, fuck you developer guy!" says Git to me. "You will dance to my tune or ELSE all your hard work will be destroyed. Safe history is all an illusion! Your code will commit, if you've put your dash in the right place. No simple context menus for you! Mwahaha!" So I bow down to the evil overlord who holds sway over my work's safety. I do as he asks and successfully complete the mystical ritual. My code is safe, right? Sure, if no one else has gone in and caused some kind of cluster-fuck with the repo while you were working on your own stuff.
Am I saying Git is a bad thing top to bottom? No I'm not. It's a powerful tool with lots of good features. The main complaint I have is that it takes a concept that is relatively simple at its core and complicates it to the nth degree without giving me, the developer, any real benefits. Managing my code has become a morass of command line incantations, rather than the few clicks and simple visual feedback that it used to be.
Maybe I'm just getting old and can't grasp the 'simple elegance' that is Git. But I doubt it. I've designed user interfaces for dozens of complicated systems, and the implementation, documentation and user friendliness of Git could sure use a few metric tons of improvement. Just because it's made for developers doesn't mean I should have to use a text console and enter lines of nonsense to do my work and commit my code.
A task that should be so simple, shouldn't be so damned difficult to accomplish.
I'm stuck with it now, but every time I have to use it I'll be silently thinking in the back of my mind..."Fuck you Git," praying it doesn't hear me and will actually do what I want.
Please bow your heads and join me in a prayer for the safety of my code.
Comments