On Mon, 2017-04-17 at 17:26 -0700, Junio C Hamano wrote: > "Philip Oakley" <philipoakley@xxxxxxx> writes: > > > > > I'd guess that the misunderstanding is that you maybe thought that > > the > > whole directory would be reset to it's old state and the files b and > > c > > deleted, rather than just the named files present in that old commit > > being extracted. If we'd created and added a file d just before the > > checkout, what should have happened to d, and why? > It probably is a bit unfair to call it "misunderstanding". I've had > this entry in the "Leftover Bits" list for quite some time: > > git checkout $commit -- somedir may want to remove somedir/file > that > is not in $commit but is in the original index. Anybody who wants > to > do this needs to consider ramifications and devise transition > plans. > Cf. $gmane/234935 > > In the thread, this message: > > https://public-inbox.org/git/xmqqeh8nxltc.fsf@xxxxxxxxxxxxxxxx.google. > com/ > > may be a good summary. For clarification: I'm not saying that that's how the command should behave. I merely want the documentation to describe how the command actually behaves. Of course, being able to reset a folder to a previous state would be great, too. I have needed that several times and what I ended up doing is to delete the folder and then do the checkout. This doesn't cause problems if there are no untracked files (as of the state one wants to restore; what's currently tracked is of course irrelevant) you still need in that folder. If that's the case, one must make sure to not delete those files. I don't know whether there's an easier/better way, though. That's merely what I did. Having the *option* to reset an entire folder rather than the files in it would be great. -- Christoph