[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] git-checkout deleted files [Was: static_assert and :argdo]

From: Greg Chicares
Subject: [lmi] git-checkout deleted files [Was: static_assert and :argdo]
Date: Sun, 5 Mar 2017 14:33:09 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-01-11 21:47, Greg Chicares wrote:
> On 2017-01-11 18:00, Vadim Zeitlin wrote:
>> On Wed, 11 Jan 2017 09:50:41 +0000 Greg Chicares <address@hidden> wrote:
> [...]
>> GC> are these:
>> GC>   git reset --hard HEAD
>> GC>   git checkout -- .
>> GC> equally likely to throw away a useful local change that I had forgotten
>> GC> about (so that I wouldn't have moved it to trash)?
>>  Yes, "git checkout -- ." is dangerous too and, unless I'm missing
>> something, isn't really different from "git reset --hard" if you have no
>> saved changes in the index. I tend to avoid using "." with "git checkout
>> --" and use it only with the individual files, IMHO it's much simpler to
>> accidentally do "git checkout -- ." than "git reset --hard", but maybe it's
>> just because I trained myself to subconsciously pause whenever I type
>> "--hard" and ask myself whether I'm sure of what I'm doing.
> I had trained myself to avoid git-reset and instead to use git-checkout
> and specify the name of each file I'm absolutely sure I want to restore.
> Tab completion makes it pretty easy to do this.
> Then yesterday I wanted to do git-checkout to undo changes to about thirty
> files. In that case, entering the names, even with tab completion, is too
> much work, so I looked for a faster way and was surprised to learn I could
> just type '.'. But, as I later feared, it's not really much different from
> git-reset.

BTW, I believe this is the command I was seeking:

git ls-files --deleted | xargs git checkout --

It doesn't overwrite anything that's still in the working directory,
so it's quite safe.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]