Some time in the last two weeks, I pulled some code from somewhere, made some changes, and dispatched them to the author for review.
Then I scratched my head. I’d just used git.
‘Neato’.
Our Mac coder, Andrew, hates the living bejeezus out of Git. I’m worried that even this mention might have sent the normally placid guy into an eye-stabbing frenzy.
I get a sense that this is not an unusual Mac-reaction to Git. That [linked] review has a pretty interesting perspective:
I’ve observed that developers that were able to learn git from colleagues already familiar with git and its internals tend to have a higher opinion of it, in contrast to people such as myself that had to waste a lot of time digging around through Google and the man pages.
Indeed – my few hours of relatively successful git operation were largely guided.
When I tried to launch into using git for a small local project earlier this week, BAM instant and insurmountable fail.
Frankly, Git looks well worth learning, and it looks like it’s probably quite nice to work with under a Gui like Tortoise. But learning to operate it from the command line, for anything but the most trivial of activities …
Describing any part of Git as basic or “trivial” is a bit like tossing out the phrase “the part of the minefield with no mines in it”.
Let me clarify here: I have given Git more than a passing glance. I’ve actually revisited Git a number of times, but each time I ultimately reach a depth of frustration that makes me do a mental “rollback” on everything I’ve learned.
The combination of Git’s ability to do anything and its friendly habit of telling you when you’re doing something none too smart is deceptive. Using Git very easily descends into an option-fest, in the process of which you are going to give Git the impression you know more than you’re letting on. At this point, assumptions become involved. And suddenly you’re doing very bad things but you’re not going to know about them until it comes time to, say, pull latest updates and find that there are no updates because the last sequence of commands you uttered was a secret Git code for “destroy repository” or “convert repository to latest revisions only with no history” (I’m being ridiculous there, but it’s not impossible Git would let you do those things).
I don’t see the Gituation changing, though. Technically, Git is genius. But I don’t see Linus appointing someone to make Git user friendly. It does what he needs, and when it doesn’t, he’ll fix the omission. He could appoint a lieutenant to lead a major documentation makeover, but that would no doubt lead to requests for alterations to the interface, to which Linus is just going to say “you can do that with …”.
There are options like EasyGit and – as I mentioned – TortoiseGit, but both are at the mercy of changes to the development of the underlying Git systems and the user is perhaps more likely to walk into Git boobytraps.
Ultimately, Git takes time and effort to learn; it seems any such effort is likely to be well rewarded. But if you’re just looking to get code into Source Control … look to Subversion, Mercurial, Darcs or Bazaar.
Bazaar actually sounds kind of interesting to me, because it appears to offer a little more convenience for working off of a centralized master repository. But somehow it appears to have slipped under most folks’ radar.
Darcs has some really interesting concepts, in particular it supports a “search and replace” patch type:
Imagine you change every instance of “LoadDataFromDisk” in a branch to “LoadDataFromSource”. With a normal VCS, when you go to merge your code with someone elses. Unfortunately, they added a bunch of new calls to “LoadDataFromDisk”. In the resulting merge, all the lines you specifically changed will be changed, but all the new mentions will go unmodified.
With Darcs, if you record the renames as a search-and-replace patch, it will be applied to the code you are merging in, so that the new lines will have the correct function name.
Would really like to see a few more VCSes support that kind of neatness.
kfsone's pittance 
5 Comments
The goggles, they do nothing!
I realize what I am writing below is getting longer and longer, and a bit rambling. Please bear with me!
Git is a real ‘love it or hate it’ VCS.
I’m a PHP developer and personally, I love it – I find it far superior to any other version control systems I’ve ever used, although granted, that experience on extends to CVS, SVN, and dabbling with mercury (which would be my second choice).
However, there seems to be a strong correlation between how people feel about git, and what their background is. From people I talk to, those that hate git most seem to have a lot of experience with other systems such as SVN / Bazaar / hg etc.
Meanwhile, those that are introduced to git as their ‘first’ VCS with guidance from coworkers come to love it, and have a tendency to rail against other, more limited version control systems when they end up having to use them.
Git seems to have a lot in common with mid-90’s versions of Linux, IMO. At least insofar as the comments made by people migrating to it sound a lot like the complaints long-time Windows users had when first dumped to the command line in Red Hat 5.
I guess I am not sure where git really falls apart for most people. The standard fork / branch / push / pull / rebase etc. commands are pretty straightforward. Resolving merge conflicts can be a pain in the ass, but on the flip side, being able to do regression testing is wonderful for finding exactly where and when bugs were introduced.
I think the biggest problem with Git is that it is overwhelming. It gives an unprecedented amount of options and control in a VCS. Most users probably won’t use even a small portion of the commands and options available, yet there is a certain practical value in knowing them all for some of the ‘what if’ scenarios using Git and it’s many options can get you into.
From the point of view of using git for a few years on a variety of projects, I think learning it from the command line, however arcane and frustrating it may be, will massively pay off.
Notice I suggested command line above – I’ve dabbled with several of the GUI frontends for Git, and they have all been underwhelming. In the attempt to simplify and make git ‘user-friendly’, they wallpaper over a lot of it’s functionality. The problem is, when you have a repository issue to deal with, you have to resort to the command line anyways to fix it in most cases. If you aren’t comfortable with command-line git in it’s basic usage anyways, having to use it to resolve some mystic message isn’t going to make you any happier with it.
You are probably aware of these resource, but work through the Git book: http://book.git-scm.com/index.html
It’s invaluable for learning git.
If you get yourself into one of the WTF situations you describe above, don’t hesitate to jump into #git on Freenode. There are a lot of incredibly helpful people there who can guide you out of the deepest part of the minefield.
As a closing note, Git is an advanced VCS which tends to fly in the face of long-standing conventions developed by other systems. It can give arcane / descriptiveness messages when something is wrong, and as part of it’s inherent flexibility to thoroughly shoot yourself in the foot. However, once learned, it’s the most powerful, flexible and rewarding VCS out there, in my opinion. Kind of like Linux was in the early days.
Cay: Each time I’ve made some kind of a successful foray into Git is when I’ve gotten slammed with the booby-trap effect. I have no tolerance for the whole cycle of “When I typed ‘git blah’ it exploded on me”, “well why the hell did you type ‘git blah’ instead of ‘git foo -bar –baz –no-folders HEAD^’? How stupid are you to be using git blah?”, “but ‘git blah’ is what it said in the manual page”, “no, that changed a week ago. do you not read the patch notes?”, “actually no, between my windows machines, my ubuntu machines and my fedora machines, the daily stream of patch notes is more than I can handle”, “well fuck off and die then”.
hah. That gave me a bit of a chuckle, because everyone has had ‘support’ conversations like that.
I guess it comes down to you probably don’t feel it’s worth your time to continue with git; fair enough! It sounds like you’ve managed to have unusually bad luck with it.
All I can do is recommend it; I think if learned, it will be a major productivity boost. However, if it consistently leaves you with a QWERTY imprint on your forehead from slamming it into the keyboard, then stick with mercurial or your VCS of choice if it fits your use cases.
I’m in agreement with the fact that it’s worth learning, merely saying that you need to go ahead and learn it before sequestering your most treasured lines of code to it. I’ve been unlucky because I’ve rushed ahead every time I felt I had gotten “enough” figured out, only to find out that the set of command line switches recommended on some man page or web page some place turn out to be out of date and presently exceptionally dangerous :)