Ok, when I do $ rm *.* $ git checkout versionA . I'm getting ABC.txt, AC.txt, BC.txt which is wrong as only the first two files went into version A Paradoxically $ rm *.* $ git reset --hard versionA produces the desired result! I picked up a few cases like this with git-checkout today. Usually a file or two gets copied into the working tree that shouldn't have been (and I'm clearing the working tree before each checkout, so its not "leftovers", its defo git-checkout doing it) Its coming back to me now - when I was writing my "warm-up" I tried both git-checkout and git-reset, to do my "rollbacks" and git-checkout produced a few inconsistent results like above, so I decided to stick with git-reset (this was before I knew the dangers of git-reset of course!) for "safety". Could it be that all the "vandalism" I've perpetrated to the history by resetting in a FORWARD direction could have corrupted the history somehow ? Even so, you'd expect something vanilla like $ git checkout not to be affected. I'm gonna try the checkouts without doing any resetting beforehand (i.e. no messing with the history) to see if I can reproduce this. "Zorba" <cr@xxxxxxxxxxxxx> wrote in message news:gjdh0r$n3c$4@xxxxxxxxxxxxxxxx ** have now promoted git-checkout as the way to review older versions I've left git-reset in there, for my own notes as much as anything, but not suggesting it be used as some sort of cursor to move the HEAD up and down the branch NB getting some funny results with git-checkout near the head of the branch - will investigatge and report -- 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
