Re: [boost] [git-help][urgent] How do I ignore an upstream change to one file?

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]
> wrote:

> On 29/12/2013 08:16, Cox, Michael wrote:
>
>> On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener <eldiener_at_[hidden]>
>> 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