> 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. >Git is about "contents", not "files". You modify a file, and >restore its contents to its pristine state. It is not "restore the >file", as Git is not about "files". 'Restore to its pristine state' does convey the flavour of what happens. Plain 'restore' by itself doesn't, really. >I think "overwrite is better" is primarily coming from not thinking >in terms of "Git tracks contents, not files". 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. -- Ed Avis <eda@xxxxxxxxxxxxx> -- 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