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

On 12/30/2013 08:23 AM, Beman Dawes wrote:

On Sun, Dec 29, 2013 at 3:40 PM, Phil Richards

...

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