Bug 451926

Summary: "Git Remove" should default to "git rm --cached"
Product: [Applications] dolphin Reporter: kevin
Component: plugins: gitAssignee: Sebastian Dörner <sebastian>
Status: RESOLVED DUPLICATE    
Severity: normal CC: kfm-devel, lemmyg, nate
Priority: NOR    
Version: 19.12.3   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description kevin 2022-03-26 12:11:29 UTC
The right-click "Git Add" in this plugin adds the file/folder to the staging area.  It might logically be expected that the accompanying "Git Remove" would remove the file/folder from the staging area (but keep it on-disk in the working folder).  However, it not only removes the file/folder from the staging area BUT ALSO deletes it from the working folder.  Nor is the deleted file/folder available in the wastebin.  It would be safer (and more logical) to have the "Git Remove" option default to "git rm ---cached" instead of "git rm".

This is raising the same issue as https://bugs.kde.org/show_bug.cgi?id=414342, where a fix was proposed: https://phabricator.kde.org/D25431.  However, that fix has been marked as "requires changes to proceed" since 2020, and it looks as if the fix was never applied to the plugin, hence my raising it again.  If using --cached by default causes problems as referred to by David Edmundson, I would suggest a sensible approach in the meantime would be to raise a dialogue box saying "This will nuke your files - do you REALLY want to do this?", with a Yes/No answer.  The git fsck approach suggested by Nate Graham does not work with (eg) pdfs.
Comment 1 galder 2022-03-27 09:27:59 UTC
Hello,
Would not be better if you raise the issue directly 
In the existing ticket?
https://bugs.kde.org/show_bug.cgi?id=414342

Looping Nate

Regards
Comment 2 Nate Graham 2022-03-27 21:47:55 UTC
Yep, that looks like the same thing.

*** This bug has been marked as a duplicate of bug 414342 ***