Stefan Beller <sbeller <at> google.com> writes: >So in one mode, we do actually warn about contents going missing, and the >other mode is designed to actually make things go missing without any >warning.
I think this is a big part of the issue. Two rather different operations are given the name 'checkout', and the safety standards applied to them also differ greatly. The manual page doesn't make it clear that it can be quite a dangerous command to run, even without --force. >If I were to come up with a name for such an action it's >maybe "reset" or "reset-file(s)". Agreed. Or 'git clean' could become more powerful and able to reset file contents as well as deleting untracked files. The name and documentation of 'git clean' already make it clear that it's not something safe to run without thinking first. Julio H. asked how I had learned to run 'git checkout .'. I think it was just word of mouth. I had deleted some files from the working tree and asked a colleague how to restore them from the repository - which is, after all, a bread-and-butter operation for any version control system. What is the correct command to run, then, to safely restore missing files? And yes, it probably would be better to use git's native mechanisms to throw away local changes to a file, rather than the sledgehammer approach of just deleting it and checking it out again. Most of the time I do so. Sometimes when everything is a real mess it is more straighforward to reach for 'rm' - or indeed for the delete option in your IDE or file browser. -- Ed Avis <e...@waniasset.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
