Bug 414342 - usability: "git remove" kills file into a dangling blob; use --cached argument for safety
Summary: usability: "git remove" kills file into a dangling blob; use --cached argumen...
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: plugins: git (show other bugs)
Version: 19.07.80
Platform: Manjaro Linux
: HI grave
Target Milestone: ---
Assignee: Sebastian Dörner
URL:
Keywords:
: 451926 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-11-20 21:32 UTC by fire f.
Modified: 2022-03-27 21:48 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
firefox: Usability+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fire f. 2019-11-20 21:32:44 UTC
SUMMARY


STEPS TO REPRODUCE
1. git init
2. touch aaa
3. git add aaa
4. in Dolphin, right click and click "git remove" while file "aaa" is marked

OBSERVED RESULT
file "aaa" is destroyed forever! Not in trashbin or anything! gone forever!

EXPECTED RESULT
file aaa should be ignored or booked out of git i.e. "unstaged", but of course REMAIN ON DISK !


SOFTWARE/OS VERSIONS: Linux/KDE Plasma, see above
Comment 1 Nate Graham 2019-11-20 21:40:56 UTC
That's just what git's remove operation does: blows away the file on disk. If you don't want files in your git repo removed on disk, don't use git's remove operation.

Now, this should probably be undoable, since we're in a GUI file manager after all. But the bottom line is that this is just how git works. It is definitely not known as the most user-friendly source control tool! Am I understanding that you were intending to un-stage the file, i.e. undo an accidental action to add it to the list of staged files?
Comment 2 fire f. 2019-11-20 21:44:35 UTC
yes, since the instruction "git remove" does not even exist, just like the instruction "cheryypick" asf., I expected to definietly keep the file on disk, just book it out of git. It coulkd at least been trash-binned !
Comment 3 fire f. 2019-11-20 21:47:44 UTC
meaning that "git remove" just reverses "git add" but not totally destroy it. That is what intuitively many would presume.
Comment 4 fire f. 2019-11-20 21:52:15 UTC
(In reply to Nate Graham from comment #1)
> If you don't want files in your git repo removed on disk, don't use git's
> remove operation.

my file was not even "in the git repo" proper, since no commit was yet made.

So the menu entry should change from "git remove" to "git destroy" to not let anyone believe the file can be gotten back from the git repo necessarily.
Comment 5 David Edmundson 2019-11-20 21:53:15 UTC
"git rm" does exist. "rm" is short for remove. 

Trashing a file that's managed by git wouldn't make any sense. If you want to recover it, you'd use git ways rather than mix strategies. 


>file "aaa" is destroyed forever
FYI, if you do accidentally git rm a staged but uncommitted file, run git fsck and then look through your dangling blobs. There's a chance it's recoverable.
Comment 6 Nate Graham 2019-11-20 21:55:36 UTC
Looks like `git rm` has a --cached option that will keep the file on disk in this particular use case (file was just added to the repo and is not yet in the history). That's probably what the git plugin should use.
Comment 7 Nate Graham 2019-11-20 22:06:36 UTC
Here's a patch that should fix it: https://phabricator.kde.org/D25431
Comment 8 fire f. 2019-11-20 22:09:23 UTC
An icon "delete file" has been present forever, and people know hwt it means.

For usability's sake, there should be a "git ignore" icon.

"git remove" seems redundant, since it just does the same as "file delete".

People do not expect to have their files destroyed forever in git.
Comment 9 fire f. 2019-11-20 22:11:00 UTC
Thanks, Nate, wonderful !

indeed,


 git fsck --name-objects

 git show 6809d……


will display the "lost file" to make a copy !


glad, I  got the file back. Feels like bit of a rough edge initially!

Again, thanks for your help!
Comment 10 fire f. 2019-11-20 22:27:04 UTC
Thanks David as well!
Comment 11 Nate Graham 2022-03-27 21:47:55 UTC
*** Bug 451926 has been marked as a duplicate of this bug. ***