activity wholist changelog info go back go back go forward go forward
now if you've got a pair of headphones... - counterintuitive nipples
you'd better get 'em on and get 'em cranked up
ajaxxx
ajaxxx
Add to Memories
Share
counterintuitive nipples
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:
music: front line assembly - future fail

Comments
neillparatzo From: neillparatzo Date: June 22nd, 2008 05:43 pm (UTC) (link)
I object to using git on the basis that there's no TortoiseGIT.
From: (Anonymous) Date: June 23rd, 2008 03:03 am (UTC) (link)
See git-cheetah for something that aims to be a TortiseSVN clone.

See qgit if you want to use git on Windows now.
From: rhpennin Date: June 22nd, 2008 06:46 pm (UTC) (link)

well...

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.
ajaxxx From: ajaxxx Date: June 22nd, 2008 07:16 pm (UTC) (link)

Re: well...

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...
robbat2 From: robbat2 Date: June 22nd, 2008 09:53 pm (UTC) (link)

Re: well...

My coworkers love the Git interface for TextMate.
mihmo From: mihmo Date: June 22nd, 2008 08:11 pm (UTC) (link)
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.
zaitcev From: zaitcev Date: June 23rd, 2008 12:49 am (UTC) (link)
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.
jldugger From: jldugger Date: June 22nd, 2008 09:06 pm (UTC) (link)
Why must we compare Git to CVS? Nobody likes CVS, they merely put up with it. How do you feel Git compares to say Bzr?
From: fooishbar Date: June 23rd, 2008 12:40 am (UTC) (link)
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
From: fooishbar Date: June 23rd, 2008 12:42 am (UTC) (link)
(In case it was unclear, the failure was a relatively cryptic error message. 'bzr pull' was what I was after.)
jldugger From: jldugger Date: June 23rd, 2008 03:57 am (UTC) (link)
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.
From: fooishbar Date: June 23rd, 2008 11:23 am (UTC) (link)
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.)
From: dgh Date: July 5th, 2008 09:01 am (UTC) (link)
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.
pong! (x13) || ping?
$ ph
Adam Jackson
User: ajaxxx
Name: Adam Jackson
$ cat .plan
gpg: DD38 563A 8A82 2453 7D1F 90E4 5B8A 2D50 A0EC D0D3
$ nm -D
$ cal
Back November 2010
123456
78910111213
14151617181920
21222324252627
282930
page summary
tags