Comment by jjoonathan | Hacker News Reader

Comment by jjoonathan | Hacker News Reader

Parent Full thread

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.

`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.

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.

Reply on news.ycombinator.com