3 ms·

Except that `checkout` makes the working copy match the target branch, which destroys the pending changes in the working copy, if a path is specified. It's the

by fryguy 12y ago

Except that `checkout` makes the working copy match the target branch, which destroys the pending changes in the working copy, if a path is specified. It's the same as `revert` in other version control systems.

ianlevesque 12y ago
It doesn't overwrite uncommitted changes.
- throwawayaway 12y ago
  it does too: https://news.ycombinator.com/item?id=8934475 https://news.ycombinator.com/item?id=8934475
lomnakkus 12y ago
Nope. It stops and explicitly tells you "I cannot do that, because that would overwrite files X, Y and Z.". Why would you think otherwise?
- oconnor663 12y ago
  "If a path is specified," which is correct. The checkout command is like two commands in one.
  - mercurial 12y ago
    Nobody ever accused the git command line UI of being user-friendly and well thought-out.
    - throwawayaway 12y ago
      > Not to be rude, but I'm baffled why a professional programmer could be "wary" of using a VCS. Or is it just git in particular? (More understandable, there's a learning curve, but nearly every major project is using it. Git's proven itself.) it's a learning curve alright.
  - lomnakkus 12y ago
    (I'm not sure "if a path is specified" was actually part of the comment when I responded, but I'll grant that...) Ah, missed that -- and I concur with the other commenter that this is bad UI. However, I don't think this qualifies as particularly dangerous or surprising behavior. You're explicitly giving a file name after all -- you had better read up on what the command does if you're doing that. ("rm X" is pretty good precedent.)
    - lomnakkus 12y ago
      (Self-reply and all, and I'm not sure anyone actually reads these old threads...) Does "checkout -- some-file" not add an entry to the reflog? (Which, btw, is one of the most important and useful commands ever in the history of VCS.)
throwawayaway 12y ago
that was my point, perhaps I could have made it clearer. git checkout <commit-hash> <filename> working copy of filename now gone if not committed.
- Igglyboo 12y ago
  You specified checking out a branch which is completely different than checking out a file by commit-hash.
  - throwawayaway 12y ago
    of course you are correct. i am sorry. i was doing it from memory. you can leave out the commit-hash too, to get the same effect. not at a computer now but i think i remember "git checkout <commit-hash> * " being extra fun. update, this is what i meant: "git checkout * " "git checkout <commit-hash> * " "git checkout <branch> * " each have the same warningless wipeout of uncommitted changes.

by fryguy 12y ago

ianlevesque 12y ago

It doesn't overwrite uncommitted changes.

throwawayaway 12y ago
it does too: https://news.ycombinator.com/item?id=8934475 https://news.ycombinator.com/item?id=8934475

lomnakkus 12y ago

Nope. It stops and explicitly tells you "I cannot do that, because that would overwrite files X, Y and Z.". Why would you think otherwise?

oconnor663 12y ago
"If a path is specified," which is correct. The checkout command is like two commands in one.
- mercurial 12y ago
  Nobody ever accused the git command line UI of being user-friendly and well thought-out.
  - throwawayaway 12y ago
    > Not to be rude, but I'm baffled why a professional programmer could be "wary" of using a VCS. Or is it just git in particular? (More understandable, there's a learning curve, but nearly every major project is using it. Git's proven itself.) it's a learning curve alright.
- lomnakkus 12y ago
  (I'm not sure "if a path is specified" was actually part of the comment when I responded, but I'll grant that...) Ah, missed that -- and I concur with the other commenter that this is bad UI. However, I don't think this qualifies as particularly dangerous or surprising behavior. You're explicitly giving a file name after all -- you had better read up on what the command does if you're doing that. ("rm X" is pretty good precedent.)
  - lomnakkus 12y ago
    (Self-reply and all, and I'm not sure anyone actually reads these old threads...) Does "checkout -- some-file" not add an entry to the reflog? (Which, btw, is one of the most important and useful commands ever in the history of VCS.)

throwawayaway 12y ago

that was my point, perhaps I could have made it clearer. git checkout <commit-hash> <filename> working copy of filename now gone if not committed.

Igglyboo 12y ago
You specified checking out a branch which is completely different than checking out a file by commit-hash.
- throwawayaway 12y ago
  of course you are correct. i am sorry. i was doing it from memory. you can leave out the commit-hash too, to get the same effect. not at a computer now but i think i remember "git checkout <commit-hash> * " being extra fun. update, this is what i meant: "git checkout * " "git checkout <commit-hash> * " "git checkout <branch> * " each have the same warningless wipeout of uncommitted changes.