Comment by djur | Hacker News Reader

Comment by djur | Hacker News Reader

Parent Full thread

They do different things, anyway. `git checkout <file>` will restore files from the _index_, which means it actually discards changes since the last `git add`. It can also be used on the entire tree as `git checkout .`. (As an aside, I think that the different branch vs. tree behaviors for `git checkout` are the biggest UX wart in git.)

`git reset --hard` discards the index _and_ any unindexed changes. You can think of it as essentially `git reset` (which discards the index) followed by a `git checkout .`

I think a lot of the murkiness of git's usability comes from the fact that many commands have collected convenience flags that replicate the behavior of other commands. The rest comes from the fact that `git checkout` and `git reset` can affect any or all of 1) the contents of the working directory 2) the contents of the index 3) the contents of repository metadata like branch tips and HEAD, and you pretty much just have to learn what does what.

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.

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.

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.

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?

Reply on news.ycombinator.com