On Sun, Dec 29, 2013 at 3:40 PM, Phil Richards wrote: On 29/12/2013 08:16, Cox, Michael wrote: On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener I am interested in this. Other than the hard reset, which tells git to overwrite the working directory and index, I did not think that git would
ever throw away uncomitted changes, whether they are in the working
directory or the index. Would you please be specific about any situations
where git will overwrite the working directory/index without the user
being
aware ? Just about any git command with a (-f | --force) option, e.g. git checkout -f HEAD
git submodule update -f
etc. Anytime you use a -f option you're telling git, "I know what I'm doing",
whether that's true or not. The only one that goes against this is:
git checkout my_modified_file
which doesn't require a "-f", and overwrites your local modified file
(without warning) with the version that is in the repository. Ok, so that was only a single file lost... but:
git checkout .
does that to the whole directory, and, of course, is completely different
to:
git checkout
which doesn't do anything harmful. That's truly horrible!
I tried "git checkout my_modified_file" myself to make sure I understood
you correctly, it wiped out the changes without the slightest hint or
warning that anything was amiss.
https://svn.boost.org/trac/boost/wiki/GitCautions has been updated
accordingly.
Does anyone know the rationale for not requiring -f or --force? Or could
this be a bug in the git checkout implementation?
--Beman