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: Peter A. Bigot (pab_at_[hidden])
Date: 2013-12-30 10:38:13

On 12/30/2013 08:23 AM, Beman Dawes wrote:
> On Sun, Dec 29, 2013 at 3:40 PM, Phil Richards <news_at_[hidden]
>> On 29/12/2013 08:16, Cox, Michael wrote:
>>
>> 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?

I'd bet a large finite amount it's not a bug.  The rationale would be 
that you told git to check out a specific file or directory, so git 
assumes you meant it.

FWIW, I have:

[alias]
         stat = status --short --branch --untracked-files=normal

in my ${HOME}/.gitconfig, and my fingers are in the habit of typing "git 
stat" at the command prompt whenever my brain hasn't fully processed the 
results of whatever I last did. (I find "git status" too noisy.)

This usually leaves a blatant "you have modified/untracked files on this 
branch!" signal still on the screen which my brain mostly notices before 
I finish typing "git checkout ." (or, more frequently, "git reset 
--hard" or "git clean -fd ." which are destructive of all modified and 
untracked files, respectively). That, and frequent use of "git add -u" 
to store unready but valuable changes in the index, makes data loss rare 
and usually recoverable.

Peter