Hacker News Reader

Comment by fendrak | Hacker News Reader

Am I the only one who thinks picking a DVCS tool based on the GUI is a bad idea? It seems to me that hg and git were designed to be used from a command line, and (for git at least) it works brilliantly. The GUI DVCS frontends try to hide a lot of the complexity of various tasks from you, but in that insulation you also end up with a clouded view of how things actually work, leading to the branching/merging mistakes the author talks about.

View on HN

He didn't write GUI, he wrote "git UI". (Or at least that's what it says now. He may have edited after posting.) So he's not picking his DVCS based on graphical user interfaces.

And I think any tool's user interface is fair game for criticism. (Though other than the infamous "How do you delete a remote branch?" issue, I like git's user interface just fine.)

I assumed that when he said "GUI" he meant "interface."

I could be wrong.

"GUI" is never explicitly mentioned, but after re-reading, I'm still not sure he _didn't_ mean a GUI, but neither am I sure that he certainly meant the CLI. I've never had a problem with the git CLI, I actually preferred it over the hg one (git pipes the log into 'less' for example, and lists entries in a sane reverse order so that the most recent log entry is on top). Maybe I'm just sensitive?

Maybe. "git has a hard cli" is a meme that's been around as long as git has. I've never found it to be particularly difficult.

...and I would never hire anyone who perpetuates that myth. I converted a large (50+) group of developers to git from an old, horrible system which will go unnamed. Only the stupid ones complained about the switch. Sorry, it's true.

Ya, I'm a little bruised over the flames that ensued during the transition but I think we're better off after having bitten the bullet. The biggest problem was always close-minded people, it was never the technology.

The git model is good enough that we use it in spite of the bad CLI, not because of it. Just off the top of my head:

* the HEAD^2~3 syntax is so obscure that I can't believe anyone actually uses it; I always give up and get a commit name from the log instead

* it will cheerfully give you a branch named refs/heads/R/B having no relationship with refs/remotes/R/B with no warnings (I have even seen peers create and push refs/heads/refs/heads/R/B by mistake)

* the index should be a hidden implementation detail, with partial commits done instead via "git stash" so it's at least possible to test them (the index is also what caused "git checkout" and "git reset" to become bizarre grab bags of mutually exclusive actions)

I would seriously like to hear a sane defense of this meme...

> git pipes the log into 'less' for example, and lists entries in a sane reverse order so that the most recent log entry is on top

Well, hg is doing the same.

Hmm, using hg for Windows last summer, it never failed to do exactly the opposite of what I described. Perhaps its just a Windows thing, or the version of Mercurial I was using.

Yes, because Windows doesn't have less. It does whatever makes sense on each platform -- so on Windows it'll also use notepad for commit messages by default, and look for both .hgrc and Mercurial.ini in the home directory.

The pager and editor are configurable, of course. I have it set up to use emacsclient on Windows.

Reply on news.ycombinator.com