* Re: Revert and reset and very damaging Git commands
2022-07-11 19:52 Revert and reset and very damaging Git commands Gerriko io
@ 2022-07-11 21:40 ` brian m. carlson
2022-07-11 23:20 ` Thomas Guyot
0 siblings, 1 reply; 3+ messages in thread
From: brian m. carlson @ 2022-07-11 21:40 UTC (permalink / raw)
To: Gerriko io; +Cc: git
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread