# Fwd: git rm 7 messages from 2016-07-05 to 2016-07-10. Participants: Peter, Andreas Schwab, Jeff King. Thread: https://gitlist.dev/t/42785 ## Peter, 2016-07-05 21:55 Subject: Fwd: git rm Message-ID: URL: https://gitlist.dev/e/CAK8tuqhMiHqPoK4gk7onT%2BVXsLJE5ogcpu7dc%3D_8am%2BifL%3D5yQ%40mail.gmail.com In-Reply-To: ``` Greetings to the community of this wonderful piece of software! I am a lightweigt git user so by all means not a reference, but I was wondering why exactly does "git rm" also delete the file (remove it from the working tree). I see it as an unintended behaviour as git is written in a way that it preserves the most data. Usually git commands are very basic and the usual workflow requires more consecutive commands, it even has its own shell. But "git rm" does everything in one step even though there are lots of scenarios where the file should be kept. I am aware of the "git rm --cache" command, but from my perspective "git rm --delete" is the one that is needed... GUI users and some CLI users (by using trash-put or similar tool) also use trash before removing the file completely. Does "git rm" support freedesktop.org trash specification? Thank you for your answers in advance, Peter ``` ## Andreas Schwab, 2016-07-06 16:42 Subject: Re: Fwd: git rm Message-ID: <87a8hubtw4.fsf@linux-m68k.org> URL: https://gitlist.dev/e/87a8hubtw4.fsf%40linux-m68k.org In-Reply-To: ``` Peter writes: > I am a lightweigt git user so by all means not a reference, but I was > wondering why exactly does "git rm" also delete the file (remove it > from the working tree). I see it as an unintended behaviour as git is > written in a way that it preserves the most data. The data is still preserved. You can restore it with "git checkout HEAD ". Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Jeff King, 2016-07-07 03:35 Subject: Re: Fwd: git rm Message-ID: <20160707033538.GA7595@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160707033538.GA7595%40sigill.intra.peff.net In-Reply-To: <87a8hubtw4.fsf@linux-m68k.org> ``` On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote: > Peter writes: > > > I am a lightweigt git user so by all means not a reference, but I was > > wondering why exactly does "git rm" also delete the file (remove it > > from the working tree). I see it as an unintended behaviour as git is > > written in a way that it preserves the most data. > > The data is still preserved. You can restore it with "git checkout HEAD > ". Assuming the file is present in HEAD, of course. But if it is not, then git should (and does) complain and ask for "-f". -Peff ``` ## Peter, 2016-07-10 08:38 Subject: Re: Fwd: git rm Message-ID: URL: https://gitlist.dev/e/CAK8tuqiCMUjoS_xXKSJ4qiGK8ioAjfGsQ3_WO0OQj5-5-i7rOw%40mail.gmail.com In-Reply-To: <20160707033538.GA7595@sigill.intra.peff.net> ``` So if I do: touch abc git add abc And after that I do: git rm abc Can you agree that there is an asymmetry of two commands vs. one? Git add only touches the files in .git/ and git rm ALSO affects the working tree... Is "git rm" or "git rm --cache" used more often in practice? Peter On 7 July 2016 at 05:35, Jeff King wrote: > On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote: > >> Peter writes: >> >> > I am a lightweigt git user so by all means not a reference, but I was >> > wondering why exactly does "git rm" also delete the file (remove it >> > from the working tree). I see it as an unintended behaviour as git is >> > written in a way that it preserves the most data. >> >> The data is still preserved. You can restore it with "git checkout HEAD >> ". > > Assuming the file is present in HEAD, of course. But if it is not, then > git should (and does) complain and ask for "-f". > > -Peff ``` ## Andreas Schwab, 2016-07-10 10:57 Subject: Re: Fwd: git rm Message-ID: <87bn254v7b.fsf@linux-m68k.org> URL: https://gitlist.dev/e/87bn254v7b.fsf%40linux-m68k.org In-Reply-To: ``` Peter writes: > So if I do: > > touch abc > git add abc > > > And after that I do: > > git rm abc error: the following file has changes staged in the index: abc (use --cached to keep the file, or -f to force removal) Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Peter, 2016-07-10 12:23 Subject: Re: Fwd: git rm Message-ID: URL: https://gitlist.dev/e/CAK8tuqj8_Xgp1f%2BSPArmMHQs_%2Bu6gOMnt958GXXRnTp4MAuB3g%40mail.gmail.com In-Reply-To: <87bn254v7b.fsf@linux-m68k.org> ``` Ah, ok, I see now. But are there any other situations where the "-f" switch is not needed? Peter On 10 July 2016 at 12:57, Andreas Schwab wrote: > Peter writes: > >> So if I do: >> >> touch abc >> git add abc >> >> >> And after that I do: >> >> git rm abc > error: the following file has changes staged in the index: > abc > (use --cached to keep the file, or -f to force removal) > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." ``` ## Andreas Schwab, 2016-07-10 12:45 Subject: Re: Fwd: git rm Message-ID: <874m7x4q6g.fsf@linux-m68k.org> URL: https://gitlist.dev/e/874m7x4q6g.fsf%40linux-m68k.org In-Reply-To: ``` Peter writes: > Ah, ok, I see now. But are there any other situations where the "-f" > switch is not needed? When the file is unmodified and matches the index. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ```