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
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?
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 !
meaning that "git remove" just reverses "git add" but not totally destroy it. That is what intuitively many would presume.
(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.
"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.
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.
Here's a patch that should fix it: https://phabricator.kde.org/D25431
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.
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!
Thanks David as well!
*** Bug 451926 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/sdk/dolphin-plugins/-/merge_requests/76
(In reply to Bug Janitor Service from comment #12) > A possibly relevant merge request was started @ > https://invent.kde.org/sdk/dolphin-plugins/-/merge_requests/76 We now have a "restore staged"/unstage action that should be used instead of the `remove` action for this use case. https://invent.kde.org/sdk/dolphin-plugins/-/commit/6c438e9076f88d2065031a149295f4886c321b67 If we use --cached for the remove action, we would have two actions doing the exact same thing (removing from index). We might want to remove the "Remove" action now.