I really liked your "Git in 600 words.[1]" I think it will help clear up some confusion for some of my VCS wary colleagues.
1. http://maryrosecook.com/blog/post/git-in-six-hundred-words
1. http://maryrosecook.com/blog/post/git-in-six-hundred-words
'cos clearly whatever he was doing was acceptable up till that point.
where did my changes go?
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?
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.
has the same behaviour. does it not? I left out the asterisk as I was working from memory.
Why would you think otherwise?
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.)
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.)
it's a learning curve alright.
git checkout <commit-hash> <filename>
working copy of filename now gone if not committed.
update, this is what i meant:
"git checkout * "
"git checkout <commit-hash> * "
"git checkout <branch> * "
each have the same warningless wipeout of uncommitted changes.
http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
Not exactly a 'how it works' article, more how it can work really well