On Mon, 2017-04-17 at 17:31 -0700, Junio C Hamano wrote: > "Philip Oakley" <philipoakley@xxxxxxx> writes: > > > > > > > > > > > > > > If we'd created and added a file d just before the checkout, > > > > what > > > > should > > > > have happened to d, and why? > > > I understand what the command does. It behaves perfectly as I > > > expected > > > it to. I did not find this script but wrote it to demonstrate that > > > what > > > the documentation says is different from how it behaves after > > > having > > > read what the documentation says it should do and noticing that > > > that's > > > not how I expected it to work from experience. > > > > > > What it really does is to copy all files described by the given > > > paths > > > from the given tree-ish to the working directory. Or at least > > > that's my > > > expectation of what it does. > > > > > > The documentation, however, says that the given paths are > > > *restored*. > > > This is different. > > I don't see that difference in the phrase *restored*, compared to > > your > > 'copy all files described by the given paths'. Could you explain a > > little more? > I am obviously not Christoph, and I was the one that defined how > "checkout <tree> -- <pathspec>" should work, but when you say > "restore" (which is not what I wrote ;-)) it is fair to expect lack > of 'd' could also be "restored", in addition to path that was in the > directory. Yes, you didn't write "restore" but you wrote: "It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit)." I suppose that from reading this, some people will assume that `d` is gone after the command was executed because the folder to which the given path leads is updated "in the working tree from the index file or from a named <tree-ish>", and others will not be sure what happens. But I doubt that a lot of people guess the behavior correctly and are sure about them being correct. Note that for the first group of people, it doesn't matter that git doesn't track folders. You can restore a folder "in the working tree from the index file or from a named <tree-ish>" without tracking folders because there only is one property of a folder git cares about, apart from it itself being able to access files in that folder: Its name. And it can get that name from the paths of the files in that folder. If there are no files in that folder, there isn't a contradiction, either, because then there is no folder in the index or tree-ish which can possibly be restored. > Obviously, "grab all paths that match <pathspec> out of <tree>, add > them to the index and copy them out to the working tree" will never > be able to _restore_ the lack of 'd', even it may match the > <pathspec> being used to do this checkout, by removing it from the > current index and the working tree. Exactly. "grab all paths that match <pathspec> out of <tree>, add them to the index and copy them out to the working tree" is a more accurate description of what the command does (but it might need some rewording ;-) ).