Re: [PATCH] git-checkout.txt: Document

I agree, the word 'revert' is already taken for the operation of creating a new commit which undoes some earlier commit. So 'revert' cannot be used for the operation of overwriting a working tree file with its contents from the repository.

But just because 'revert' is not a good choice, doesn't mean that 'restore' is either.

'Restore to its pristine state' does convey the flavour of what happens. Plain 'restore' by itself doesn't, really.

But 'git checkout .' is primarily an operation on the local filesystem. As far as I know, it does not change the git repository, nor the index, stashes and so on. Its only effect is to create and overwrite local files, much the same as 'tar x'. So the appropriate language to describe it should be based more in common usage rather than git-specific terms - if indeed 'restore' is the git-specific term for replacing a file in the working tree. (In which case why not call the command 'git restore'?)

If indeed it did work by tracking contents, there wouldn't be a problem. The old contents of the file could be saved as a stash and then the file's contents replaced with the version from the current commit.

% git checkout .
The following files have been restored to their pristine state:
   foo
The previous contents have been saved and can be got back with:
   git stash apply checkout_backup_abcde

Then there would be no need for agonizing over the documentation to make it clear that 'git checkout PATH' can be a dangerous operation, because it would no longer be dangerous.