On Sun, Dec 29, 2013 at 3:40 PM, Phil Richards <news@derived-software.ltd.uk
wrote:
On 29/12/2013 08:16, Cox, Michael wrote:
On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
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