6 ms·

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 l

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

jerrysievert 12y ago
i once took a leadership position at a small company that had a longtime contractor building one of their core web products out of foxpro. he refused to use any VCS, proclaiming that "version control is for the weak". needless to say, he didn't last very long.
- test1235 12y ago
  He didn't last very long because he didn't agree with you? 'cos clearly whatever he was doing was acceptable up till that point.
  - toolz 12y ago
    There's no real opinion being given here. That would be like suggesting a general contractor on a new home was fired for difference of opinion, when the reason was he just didn't have insurance.
throwawayaway 12y ago
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
recursive 12y ago
I think it's git in particular. Git can seem like it has more complexity than is necessary for a version control solution for some arbitrary "simple" project.

jerrysievert 12y ago

i once took a leadership position at a small company that had a longtime contractor building one of their core web products out of foxpro. he refused to use any VCS, proclaiming that "version control is for the weak". needless to say, he didn't last very long.

test1235 12y ago
He didn't last very long because he didn't agree with you? 'cos clearly whatever he was doing was acceptable up till that point.
- toolz 12y ago
  There's no real opinion being given here. That would be like suggesting a general contractor on a new home was fired for difference of opinion, when the reason was he just didn't have insurance.

throwawayaway 12y ago

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

recursive 12y ago

I think it's git in particular. Git can seem like it has more complexity than is necessary for a version control solution for some arbitrary "simple" project.