Comment by slaymaker1907 | Hacker News Reader

Comment by slaymaker1907 | Hacker News Reader

My biggest complaints with git is more around how it is difficult to throw away changes and how ignoring files is such a stateful process. I almost never need something nearly as specific as "git checkout" or "git reset". I generally either want to throw everything away up to the last local commit or I want to throw away everything and get my version to be the same as the branch on the server/another local branch. If I need something more fine grained, I will still do this, just on a per file basis. At no point have I ever wanted to just get rid of untracked files.

That leads to my next point about ignores. I hate that I have to manually untrack a file even if it would be ignored according to a new ignore file. The best practice there in my opinion would be to explicitly exclude said file IN THE IGNORE FILE ITSELF from being ignored. The other problem with ignore rules in Git is that for some reason Git tries to hide the fact that it has a per repo ignore file in the .git folder which doesn't get synced at all.

Instead of having untracked/tracked files, I would really rather just use ignore files, both local and remote, so that excluding something from being committed is an explicit action.

It is also really absurd that you can reset everything with `git reset --hard` but you have to use `git checkout -- ` to reset individual files. It's not even clear why `checkout` is involved in resetting files at all.

`git reset --hard` resets your worktree to the HEAD state.

`git checkout -- <file>` checks out the HEAD version of a given file.

Yes, but you can also word it in two other ways that make the redundancy more apparent at the cost of a tiny bit of inaccuracy:

A:

`git reset --hard` checks out the HEAD version of your worktree.

`git checkout -- <file>` checks out the HEAD version of a given file.

B:

`git reset --hard` resets your worktree to the HEAD state.

`git checkout -- <file>` resets a file to the HEAD state.

I don't think a newbie could even grok the difference between these three descriptions.

git reset --hard does not only modify the work tree though, it also updates where your current branch points to. In fact, that is the main purpose of ‘git reset’, the fact that it modified your work tree at all is only because of the ‘--hard’ flag. So it’s not correct to say that “reset --hard and checkout do basically the same thing”.

  git reset --hard HEAD

Does in fact only modify the work tree, since updating the current branch to HEAD is a nop.

You could word it that way, but it's not actually correct. Check the man pages to see why. (Or read the other commenter's note which gives a brief explanation.)

> I don't think a newbie could even grok the difference between these three descriptions.

This part is definitely true - Git offers only a very light abstraction on top of its data structures.

  git-reset - Reset current HEAD to the specified state
  git-checkout - Switch branches or restore working tree files

reset works primarily to modify HEAD, and when you include `--hard` it's like saying: oh and btw also update the working tree.

checkout works primarily (in the case of checkout <pathspec>) to copy file from somewhere (commit, index) into the working tree. You can use checkout to mimic a hard reset: `git reset --hard` is pretty much equivalent to `git checkout HEAD .`

I understand how it works, but I still think it's dumb.

Is it perhaps because most people are taught about `reset --hard` early on? If all they knew was `checkout` there wouldn't be any confusion.

Nobody really needs to know about `reset --hard`, the same effect can be achieved with a normal reset and a checkout, it's a two step process anyway, regardless of how you do it.

Using reset+checkout is not the quickest but gets the job done. Power users can create themselves a shell alias, or write themselves a small shell script, or learn about one of the thousands commandline switches that does just what they need.

For me, checkout is easy to remember because I'm literally checking out an older version of the file.

The future is `git restore` and `git switch`, which clear up the ambiguity between different modes of reset/checkout.

The logic is that you checkout the old file from the repository into your worktree, overwriting it.

If there's something inconsistent about this, it's that it works for individual files, but (fortunately) not for clobbering your entire worktree by checking out a branch.

I find that I often want to throw everything away except 2 files. Occasionally I want to stash everything except 2 files. These are both especially hard to do, especially if you renamed or copied a file, which is now a staged change.

> I want to throw away everything and get my version to be the same as the branch on the server/another local branch.

Isn't that `git reset --hard remote/branch` ?

That doesn't remove untracked files. You need to do the memorable "git clean -fd" to get rid of those. This is my point: two commands for what should be doable in one simple command.

Reply on news.ycombinator.com