I tire of people objecting to using git on the basis of bad documentation and UI obscurity. There seems to be a common blind spot here, which is that CVS (which everyone learned first) is just as bad, if not worse. The CVS manual has been getting steadily worse over time, and I challenge anyone reading about cvs up -j for the first time to correctly explain it, let alone sticky tags or binary file handling.
More fundamentally, I think people forget that source control is a very weird and very hard problem. Much like the lower levels of particle physics, you kind of have to implement the behaviour you expect using a model that's not intuitive. That the doc writers for git seem to revel in spewing nerdporn words like "tree-ish" at you is unfortunate, but people like seeing dmesg spew at boot for the same reason: it's obscure and therefore makes you feel cool.
Of course, no one needs to know how pretty much any vcs works under the skin on a daily basis, and that's why sensible git documentation exists. HELLO PEOPLE THE INTERNET HAS SEARCH NOW.
Tags: git music: front line assembly - future fail
People complain about git so much because they're using it, and it would be nice to fix it so it could "win" and we could avoid 400 flavors of source control. There are two reasons git doesn't "win": 1) UI and docs are _still_ abysmal and 2) cross-platform story including IDE integration sucks. If those were fixed you'd see rapid consolidation of the open source world on git, imo. git has momentum but those two points are showstoppers for some, that limit growth.
git has a lot of just egregiously, gratuitously bad UI and docs. It can't be blamed on source control being hard. Almost all the other systems have done better, and EasyGIT shows how git could be greatly improved with "surface" changes. The git maintainers should just adopt all the EasyGIT changes wholesale, and they'd be in a much better spot to evolve from.
It's not like anyone associated with git has been shy about criticizing other source control systems. So I have trouble feeling bad when they get 100% accurate criticism of git's UI design and docs. Most people concede that the basic premise and function of git is cool and nicely done.
The problem I have with easygit is the same problem I had with cogito: I find it impossible to use without knowing what git's doing under the skin, so why bother. I may be unique in this.
And I'm not defending the base documentation. I think it's crap. But near as I can tell, this is also true for cvs and svn. There's icky warts all over the place and the svn ones are just comfortable because we all grew up with cvs.
I have trouble caring about the Windows support thing, either personally or professionally. But they do keep rewriting the shell bits in C...
Yeh, I've read through docs & tutorials and I still have a lot of trouble with git. I know I need to learn it and I know as I get more experience I will get better at it. But blowing off steam about how mind twisting it is helps me cope.
It certainly has a lot more features and abilities that I will likely never need.
My experience was that you absolutely must understand how git works, however superficially, in order to use it. The first thing was the relationship between the repository, the cache, and the working directory. Second is, git's idea branch (which is entirely useless for kernel, except that git implements pulling and merging using branches internall). I had had no foggiest idea about the design of CVS during the decades I used it. So, at first I tried the same with git and it just does not work.
bzr fails because I try to clone stuff, and it says, 'oh, you have 0.13, we changed the revision yet again and you need 0.18, but good luck finding anything newer than 0.15'.
Plus, can you explain this to me?
daniels@psyence:~/src/postr.dev% time bzr get bzr: ERROR: command 'branch' requires argument FROM_LOCATION zsh: exit 3 bzr get bzr get 0.19s user 0.05s system 7% cpu 3.239 total
The 'time' bit doesn't require explanation, it's just unbelievably lame. In both respects, cf.: daniels@psyence:~/src/postr.dev% time git clone you must specify a repository to clone. zsh: exit 1 git clone git clone 0.01s user 0.01s system 2% cpu 0.622 total
I should make it clear -- I'm not an expert at either git or bzr. I'm just curious whether bzr stacks up or not. Binary compatibility is a concern, but I think it goes both ways here. I remember being told by a friend of mine over a year ago that recommended practice is to run git built from source. It might be instructive if someone graphed out the internal format changes over time to make an indisputable point about the frequency of such changes. It might even be enough that the BZR team would feel forced to make a stand.
Again, I haven't used either long enough to understand them very well, but presumably the bzr error is lacking a location to get from? Are we really concerned about the speed at which these programs fail on trivial non-input? I have no doubt that Torvalds and like minded systems programmers can beat out a python app on simple tasks. A much larger concern I think would be operations on large source trees.
The point was that despite bzr's supposedly best-of-class UI, that error is stupidly cryptic. I defy anyone to tell me that that's a more intuitive error message than git. (Of course, 'bzr pull' isn't documented in the help either. To get new changes according to the help, you do 'bzr merge', which makes sense only if you were a heavy TLA user before, which is true for both myself and the entire bzr team.)
CVS being rubbish is no excuse for problems in Git. I agree that VCS is hard to do, but most of Git's UI problems are not because of some fundamental complexity. I personally get on ok with Git now, but watching friends and colleagues getting started with it is often miserable.
I like git, but I don't feel I can wholeheartedly recommend it. Which is a shame when I think that the usability is largely fixable.