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? The only case I know of where there will be files left over is if you switch from a situation where you have an untracked file (e.g., you create C.txt but don't add it to anything) to another situation where the file still isn't tracked, it won't remove it. But, of course, you wouldn't really want git to remove your uncommitted work in general, since it's generally irreplaceable. It'll only be lacking files if it fails to switch (if, for instance, you had uncommitted changes that conflict with the changes that it would do), and it will give an error message in that case. > if you must have > > git checkout <something> <paths> > > then instead use > > git checkout <something> <paths> > git clean > > ** hmm, might try this - obviously as per Daniels post there is some > undefined interaction happenign with the index, to screw up the working > directory. I presume clean flushes the index? git clean wouldn't remove those files, because they're supposed to be there at that point. In the sequence: ... $ git tag versionD $ git checkout versionA . This means: "Update the index with the files in versionA, and working directory from the index" So now you're working on a commit based versionD (because you didn't switch branches), and your work thus far, which is marked as ready for your next commit, is to recover the removed files ABC.txt and AC.txt (from versionA). $ rm *.* This removes those files again, but only in your working directory. Your index still says that your next commit will recover them. $ git checkout versionB . This recovers ABC.txt and BC.txt (from versionB). Your index has ABC.txt, BC.txt (from versionB), and AC.txt (from versionA), marked as going into the next commit. It also puts all of these in your working directory (when you might expect it to only put ABC.txt and BC.txt there). So (a) you're still working on the commit after versionD, rather than navagting history at all; and (b) you've recovered files from two different commits. Now: $ git clean will remove any files that you happen to have around, other than the one you're confused about and trying to get rid of. -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
