Revert and reset and very damaging Git commands

Revert and reset and very damaging Git commands

[Gerriko io]

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.

Re: Revert and reset and very damaging Git commands

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Revert and reset and very damaging Git commands

[Thomas Guyot]

On 2022-07-11 17:40, brian m. carlson wrote:
> 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