Hacker News Reader

Comment by lisper | Hacker News Reader

Yes, all this is exactly my point. It is nearly impossible to explain the current git UI in a way that isn't embarrassing at best and wrong at worst. And then it's nearly impossible to remember. The number of things you actually want to do 90% of the time is small, so I think there is value in designing a veneer that makes that 90% easy to explain and remember.

View on HN

Hg did that - unfortunately GitHub won over BitBucket, thus deciding the fate of Mercurial too.

I find Mercurial so much easier to use than Git. Many of the concepts are similar but the hg interface feels much easier to learn and use.

At $dayjob we have a mixed bag of hg and git. I found that while git makes great distinction between local and remote (and working directory), hg is more similar to centralized VCSes. Any other remote action than "sync local with remote" requires Blak Magick Mumbojumbo™. Some "common" (as seen by original authors. Local throwaway branch is not such) tasks are sure easier than git, but stepping out of the beaten path becomes cryptic. Git, on the other hand, is of average difficulty for most of the tasks. Your mileage may vary.

I'm curious, what other remote action do you miss with hg? Push and pull (to different remote repos if needed) are sufficient for me. What am I missing?

I use Mercurial as a client for git, using the hg-git extension. It works absolutely fine for my use case (small numbers of developers on github, mostly). There are a few rough edges when you want to do things that git doesn't like, like moving tags, and the bidirectional branch<->bookmark syncing isn't quite as robust as it should be, but it saves me having to touch git at all.

Reply on news.ycombinator.com