Git: It *could* be harder.
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.
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.