Subject: Re: [boost] [git-help][urgent] How do I ignore an upstream change to one file?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-12-30 09:23:25
On Sun, Dec 29, 2013 at 3:40 PM, Phil Richards <news_at_[hidden]
> On 29/12/2013 08:16, Cox, Michael wrote:
>> On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener <eldiener_at_[hidden]>
>>> 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
>>> aware ?
>> Just about any git command with a (-f | --force) option, e.g.
>> git checkout -f HEAD
>> git submodule update -f
>> 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
> 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
Does anyone know the rationale for not requiring -f or --force? Or could
this be a bug in the git checkout implementation?