threads / discuss / 58137

Revert and reset and very damaging Git commands

Subject: Revert and reset and very damaging Git commands

## tl;dr

3 messages between Jul 11, 2022 and Jul 11, 2022.

replies: 2people: 3as markdown or json

Gerriko io· Jul 11, 2022, 19:52 UTC · lore

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.

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.

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.

brian m. carlson· Jul 11, 2022, 21:40 UTC · re: Gerriko io · lore

Re: Revert and reset and very damaging Git commands

On 2022-07-11 at 19:52:05, Gerriko io wrote:
Show 5 quoted lines
> 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.

Show 5 quoted lines
> 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.

Show 5 quoted lines
> 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
Thomas Guyot· Jul 11, 2022, 23:20 UTC · re: brian m. carlson · lore

Re: Revert and reset and very damaging Git commands

On 2022-07-11 17:40, brian m. carlson wrote:
Show 16 quoted lines
> On 2022-07-11 at 19:52:05, Gerriko io wrote:
> 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.

I'd like to add that in only very few cases git will remove untracked files that haven't even been added to the index - for example git clean -f (-f is force), as it's designed to remove untracked files.

In the case of reset, it could effectively wipe untracked files but only if you reset to a revision that has these same paths, else it would not touch untracked files at all.

Added files would however be affected but as pointed out earlier they are already in your object store and can be recovered using git fsck.

If unsure about a command, especially with a name like "clean" or "reset", all command are documented and the man page can be usually read using:

git <command> --help

-- Thomas

← back to recent threads