On Thu, Oct 13, 2011 at 7:40 PM, arQon <arqon@xxxxxxx> wrote: > $ git co master > M code/renderer/tr_font.cpp > Switched to branch 'master' > Your branch is ahead of 'origin/master' by 3 commits. ... > At this point, reverting the master with "checkout --" also wipes out the > changes on the other branch. It's like the merge symlinked the two branches > rather than, well, merging them. It does show you that there are changes in the working tree and you could have switched back with "git co -", done whatever you want with your changes then switched to master again. > A couple of days ago it DID complain > when I tried to switch with uncommitted files still present, so it was working > properly then. I have no idea what's made it happy to ignore them now: > nothing's changed that I know of. git tries to keep all changes on working tree you have. If you have changes in file A and the new branch changes in file B, fine. If the new branch also changes in file A too, it'll complain because otherwise it may overwrite your changes. What it actual does is "Two way merge", there is a table in "git read-tree" man page that describes exactly how it is done, what cases would fail... I see it as more choices. As I said above, it does tell you there are changes and you could do something. You could make alias "co" that check for worktree/index cleanliness before calling checkout. Something like this maybe (I have not tested it) git config alias.co '!git update-index --refresh && git diff-files --quiet && git diff-index --cached --quiet HEAD && git checkout "$@"' A config key to enforce this may be nice. I don't know, I have never had problems with current behavior. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html