On 2022-07-11 at 19:52:05, Gerriko io wrote: > As a noob I have managed to completely delete all my local folder > contents just by misusing reset and revert commands. Un-be-lievable! > And no matter how many times I've tried I cannot return to where I > was. The git reflog is not that helpful either... and only shows > resets and not revert histories. The reflog should indeed keep track of every revision that's checked out, including reverts. Reverts act as an additional commit on top of your code, so they are part of your history. You can use `git log` or `git log -p` to view the history of the current branch, including any reverts. If you want to check out a file (say FILE) from an older revision (call it REV), you can do `git checkout REV FILE`, and that will stage that copy of the file and place it in the working tree. That can be useful to recover an older version when you've done a revert (or even when you just want the older version back). If you have files you've blown away with `git reset --hard` and you've added them to the repository, they can be recovered by using `git fsck --lost-found` to store them into `.git/lost-found` if they're not referenced by your history. If they are referenced by your history, then they can be accessed using `git checkout` as I mentioned above. If they've never been added, then they're gone for good unless you use some sort of deleted file recovery software. > Gosh this is not good. > > Why are these commands bypassing all the fundamentals of a computer > OS. Surely if a file is deleted it should end up in the computer's > rubbish bin. Not deleted permanently without a trace. In general, the programmatic interfaces used to create and delete files don't use the user trash can. That's because many programs create and delete extremely large numbers of temporary files (Git included) and it would be silly to expose those to the user, since the user trash can is designed to handle files that the user specifically might want to recover. There is also no standard portable interface for placing files into the user trash can, while there are standard portable interfaces for actually removing files. Also, traditionally, on Unix systems, deleting files has happened without prompting, and Git is designed for Unix systems. > If that is the intent then there needs to be warnings etc. for deletes > and overwrites. > > I'm just amazed that all the basics of software design are ignored for > the sake of convenience and speed. Git is a command-line tool. Command-line tools on Unix perform the task as specified silently unless there's an error. If Git prompted when using `git reset` for each file, then it would be unusable in a script, and people do frequently use Git in scripts. Also, when using something like `git clean` to clean build artifacts, there might be tens or hundreds of thousands of build files, and nobody would want to be prompted for each one. In general, you need to be very careful with `git reset` and very especially with `git reset --hard`. The latter does blow away files without notice and is very dangerous if you're not careful. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
