6 ms·

git checkout <branch> where did my changes go?

knicholes 12y ago
They're still right where they were before you switched branches unless you've committed them before you switched branches, of course!
- throwawayaway 12y ago
  mkdir commadir cd commadir git init echo "dog" >> dog.txt git add . git commit -m one echo "dog" >> dog.txt git add . git commit -m two echo "dog" >> dog.txt git log git checkout dog.txt cat dog.txt how many dogs in dog.txt?
  - bryondowd 12y ago
    That isn't "git checkout <branch>", it is "git checkout <file>" If you try checking out another branch while you have uncommitted changes, git will tell you to commit or stash your changes before changing branch. I can certainly understand the danger/confusion there, though. Using checkout on a file reverts the file to a committed state. But the grandparent was referring to checking out a branch, not a file, which is safe.
    - throwawayaway 12y ago
      git checkout <branch> * has the same behaviour. does it not? I left out the asterisk as I was working from memory.
Igglyboo 12y ago
None of those changes will be lost or overwritten. So, no where?
- 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.

They're still right where they were before you switched branches unless you've committed them before you switched branches, of course!

throwawayaway 12y ago
mkdir commadir cd commadir git init echo "dog" >> dog.txt git add . git commit -m one echo "dog" >> dog.txt git add . git commit -m two echo "dog" >> dog.txt git log git checkout dog.txt cat dog.txt how many dogs in dog.txt?
- bryondowd 12y ago
  That isn't "git checkout <branch>", it is "git checkout <file>" If you try checking out another branch while you have uncommitted changes, git will tell you to commit or stash your changes before changing branch. I can certainly understand the danger/confusion there, though. Using checkout on a file reverts the file to a committed state. But the grandparent was referring to checking out a branch, not a file, which is safe.
  - throwawayaway 12y ago
    git checkout <branch> * has the same behaviour. does it not? I left out the asterisk as I was working from memory.

Igglyboo 12y ago

None of those changes will be lost or overwritten. So, no where?

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.