Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On the other hand, if you can do this and your co-workers can't, you may be tempted to write complex and entangled code, because the implications of each line are perfectly obvious to you.


Or you end up with something like Git, which is easy to use if you have the exact same background/education/philosophy as the person who wrote it, but has terrible usability for pretty much everybody else.


I don't have the same background as the "person that wrote it," and I consistently find the git command-line tools easier to work with than other tools (SourceTree, magit-mode, vim-fugitive, etc [1]). I think that in this case, it's just the mental model of a DAG[2] of commits that people have trouble wrapping their minds around. The tools are just there to help you slice and dice the DAG.

[1] I haven't used TortoiseGit, but I do imagine that having file browser menu items for files that are maintained by git could be useful from time-to-time, but I would still be using the cli most of the time.

[2] Directed Acyclic Graph


There are more DSCM implementations based on a DAG. (for example git, mercurial, bzr, monotone, codeville, fossil)

The only one that draws serious usability complaints all the time is git.


To borrow a turn of phrase from Bjarne Stroustroup, there are two kinds of software: software people complain about, and software nobody uses.


A couple of years ago the others were in use as well.

git won for various reasons, but the UI complaints certainly aren't because people don't understand DAGs.


Yeah, the reason everyone complains about Git is because everyone uses git. SVN was the horse to beat 10 years ago, because everyone used it.


people complained about git's UI 10 years ago. They didn't complain (as much, by far) about the UI of the other DAG based DSCMs.


To be fair, some of the usability complaints aren't about the interface so much as things like:

* Unreasonable ideas about the idea that commits/history can be rewritten, so therefore "nothing is safe."

* Arguments over how some git commands are similarly named to svn commands, yet don't do the same thing. The svn way is the 'right' way, and git is 'doing it wrong,' but really it's just an argument about familiarity (sharing many traits with arguments over Mac vs. Windows keyboard shortcuts, for example).

* Complaining about a recoverable error because they don't know about the reflog.

* etc.

I'm sure there are legitimate complaints, but most of the complaints that I see are around things like that.


I consistently find the git command-line tools easier to work with than other tools

Yes, but how many weeks and months did you spend learning all the quirks? http://git-man-page-generator.lokaltog.net

that people have trouble wrapping their minds around.

If you create a product and just tell people "sorry, you're not smart enough to understand it," was it a good idea?


When git was still one of many competing DVCSes - I tried darcs, and the CLI was pretty great. Spoiled for ever.


I like to joke git's motto would be "made by people smarter than you, for people smarter than you". It still rocks.


I realize these things are subjective, but git is not difficult to understand or use. Branching is a breeze. Merging is a breeze.


Oh, but you just don't. You just don't. Six months from now, the thing will have escaped your brain and you will have to look at it.

You are generally also your own cow-orker.


If you invest the time into acquiring a faster and larger mental cache, you are unlikely to handicap your hard-earned capability with complex code. In fact, the new visibility can increase simplification and reuse.

The same restraint doesn't apply to someone naturally gifted with an exceptional memory, since they never went through the acculturation phase :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: