Hacker News Reader

Comment by lisper | Hacker News Reader

    git checkout <file> // throw away all changes since the last commit (one file)

    git reset --hard    // throw away all changes since the last commit (all files)

This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you tried to design a hard-to-use UI you could hardly do better than that.

[NOTE: these two commands actually don't do quite the same thing, which is part of the problem.]

View on HN

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.

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.

But they don't do "exactly the same thing, with the only difference being..." unless you ignore the index, which is one of the extremely powerful abstractions that sets git apart. Sure, git could expose a simplified lowest-common-denominator interface that plasters over its differences, but the same interface would (and gitless does) plaster over its strengths and encourage people not to learn them.

I agree with TFA: this isn't a UI issue, it's an abstraction issue. Several of git's abstractions only make cost/benefit sense in a distributed environment. Unbundling the cost of learning dVCS abstractions would make git a better fit for the Cathedral and a worse fit for the Bazaar. This might be what you want, but you should at least be able to understand why other people do not want it.

They don't do the same thing implementation wise, but they do the same thing ux wise. This difference causes all discussions like the above: it seems as if some people like ux "plaster", while others like bare-metal tools.

They only do the same thing if you haven't previously used `git add`. If you have, `git checkout` will use the contents of the index, not the contents of the last commit.

They do the same thing ux wise if and only if your mental model has no notion of a staging area.

I just stage parts of my changed code before commit. So things I work on are un-staged mkst of the time. Which eliminates the problem, I guess.

`git checkout` is indeed a stupid command, because it has 3 modes:

> git checkout [--detach|-b] <commit-ish>

Set HEAD to a new place and sync the working-directory/index to it.

> git checkout <paths>

Copy paths from the index to the working directory.

> git checkout <tree-ish> <paths>

Copy paths from a given commit to the working directory.

This means that "git checkout HEAD file" is different from "git checkout file".

Similarly, `git reset` has 2 modes:

> git reset <tree-ish> <paths>

Copy paths from a given commits to the index, leaving the cwd unchanged.

> git reset [--soft | --mixed | --hard] <commit>

Set *HEAD to a new place, and optionally sync the working directory/index to it.

This is obviously terrible, but changing the names now might be worse.

Then use `git checkout -f` if it so pleases you. There's more than one way to skin a cat.

To be honest, this comment is more evidence of a problem than anything else.

They are not doing the same thing. It's two completely different operations.

You'll have to take that up with /u/k__.

How so? You're the one proposing they do the same thing when they fundamentally do not. To posit so is less of git's "ux problem" and more of just needing to grok git.

I share your concerns for consistent tooling, but the idea of becoming proficient in something without putting in the effort is not reality.