Peter [off-list ref] 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
<file>".
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."
On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote:
Peter [off-list ref] writes:
quoted
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
<file>".
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
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 [off-list ref] wrote:
On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote:
quoted
Peter [off-list ref] writes:
quoted
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
<file>".
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