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