Ok, now I'm following you, cos I just "broke" checkout again by deleting files from working dirs before running it. git-checkout takes into account the state of the working tree in the commit it is run FROM, as well as the commit it is checking out. It relies on the working tree being in synch with the commit it is run from. If I delete files, I screw around with this initial state. Files that git-checkout is relying on to be there are not copied in by it, so if I've deleted (or modified) those files, hard luck. I remember s/o saying git minimizes file I/O, and this whats happening here. It puts a big demand on the user, to keep their index & working dir in synch with whats in the commit. Ah, $ git checkout . will restore the state of the working dir to be in synch with the CURRENT commit, so it will be safe to checkout other branches BINGO !! what I need to do is run the sequence $ git checkout . // tidy up current commit $ git checkout <version> // roll back n'est pas ? "Daniel Barkalow" <barkalow@xxxxxxxxxxxx> wrote in message news:alpine.LNX.1.00.0812302236190.19665@xxxxxxxxxxxxxxx > On Tue, 30 Dec 2008, Daniel Barkalow wrote: > >> On Wed, 31 Dec 2008, Conor Rafferty wrote: >> >> > -----Original Message----- >> > wtf is wrong with >> > >> > git checkout <something> >> > >> > ?? >> > >> > ** It doesn't reliably put the files that were in that revision into >> > the >> > working directory - a fairly major flaw, for what I'm using SCM for >> > (and >> > 80% of the market IMHO) >> >> It certainly does for me; I rely on it pretty much constantly. Can you >> give a sequence of commands (ideally the whole sequence from the "git >> init") that leads to a difference? > > Actually, I know what you must be doing: > > $ git tag versionD > $ git checkout versionA > (versionA in the working directory) > $ rm *.* > (versionA with ABC.txt and AC.txt deleted) > $ git checkout versionB > (versionB with ABC.txt and AC.txt deleted) > > If you've made any changes (including deleting files), "git checkout" (no > pathes) will preserve them. On the other hand, it will remove files that > are in the commit you're leaving and not in the commit you're going to. So > just don't remove the working directory files and you should be all set. > > In order to get them back if you have removed them, you can do: > > $ git checkout . > > This will discard all of the changes you've made only to the working > directory; i.e., it'll recover the deleted files. You should also try "git > status" whenever anything's mysterious, because it will tell you what's > going on. > > -Daniel > *This .sig left intentionally blank* -- 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
