|
|
Subscribe / Log in / New account

Hmm …

Hmm …

Posted Nov 4, 2018 20:11 UTC (Sun) by madscientist (subscriber, #16861)
In reply to: Hmm … by smurf
Parent article: Apache Subversion 1.11.0 released

Note the OP includes a "." at the end of the git checkout command:

> It's more about 'git checkout .' which will silently overwrite every local change in the working copy.

Adding a "." causes a checkout of all (modified) files from the current directory down. It cannot go to a different commit.

For me, if I want to un-modify a file I use "git status" to see a list of modified files, and "git checkout filex filey ..." (perhaps copy/paste) to check out specific files. If I want to throw away everything I use "git reset --hard HEAD" or similar. I virtually never use "git checkout <directory>" and wouldn't suggest it to others, either.

> what is the safe git command to bring back deleted files

By this I assume you mean a committed file that you have deleted and then want to recover and not an untracked file that you've deleted.

The best way to know how to solve almost ANY issue in a workspace is to run "git status" and it will tell you how to undo it. For example, if you "rm somefile" and then decide you want it back, "git status" will tell you:

> Changes not staged for commit:
> (use "git add/rm <file>..." to update what will be committed)
> (use "git checkout -- <file>..." to discard changes in working directory)

> deleted: Demo/readme.txt

If you use "git rm somefile" then decide you want it back, "git status" will tell you:

> Changes to be committed:
> (use "git reset HEAD <file>..." to unstage)

> deleted: Demo/readme.txt

And finally when in doubt, I use "git stash" to stash modified files before doing any kind of bizarre operations on a repository where there are modifications I want to preserve, just in case.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds