5 ms·

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 s

by slaymaker1907 5y ago

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.

ajkjk 5y ago
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.
- johnmaguire 5y ago
  `git reset --hard` resets your worktree to the HEAD state. `git checkout -- <file>` checks out the HEAD version of a given file.
  - infogulch 5y ago
    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.
    - gpanders 5y ago
      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”.
      - aidenn0 5y ago
        git reset --hard HEAD Does in fact only modify the work tree, since updating the current branch to HEAD is a nop.
    - johnmaguire 5y ago
      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.
- wereHamster 5y ago
  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 .`
  - ajkjk 5y ago
    I understand how it works, but I still think it's dumb.
    - wereHamster 5y ago
      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.
- veilrap 5y ago
  For me, checkout is easy to remember because I'm literally checking out an older version of the file.
- striking 5y ago
  The future is `git restore` and `git switch`, which clear up the ambiguity between different modes of reset/checkout.
- chousuke 5y ago
  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.
hinkley 5y ago
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.
tejohnso 5y ago
> 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` ?
- slaymaker1907 5y ago
  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.

ajkjk 5y ago

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.

johnmaguire 5y ago
`git reset --hard` resets your worktree to the HEAD state. `git checkout -- <file>` checks out the HEAD version of a given file.
- infogulch 5y ago
  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.
  - gpanders 5y ago
    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”.
    - aidenn0 5y ago
      git reset --hard HEAD Does in fact only modify the work tree, since updating the current branch to HEAD is a nop.
  - johnmaguire 5y ago
    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.
wereHamster 5y ago
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 .`
- ajkjk 5y ago
  I understand how it works, but I still think it's dumb.
  - wereHamster 5y ago
    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.
veilrap 5y ago
For me, checkout is easy to remember because I'm literally checking out an older version of the file.
striking 5y ago
The future is `git restore` and `git switch`, which clear up the ambiguity between different modes of reset/checkout.
chousuke 5y ago
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.

hinkley 5y ago

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.

tejohnso 5y ago

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

slaymaker1907 5y ago
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.