Carl Worth wrote: > But now that I tried this case with a recent git (2a3a3c247) for which > git-rm does working-tree removal without -f, I see that it does > irretrievably destroy information in this case: > > $ echo "important stuff" > new-file > $ git add new-file > $ git rm new-file > > This now deletes new-file from the working tree and there's no copy of > the data inside git. The old git-rm would just return the file to it's > "untracked" state in this case. > > I had thought the safety check was going to be that the index state > matched the HEAD state before git-rm would delete from the working > tree. That is certainly bug in new git-rm; it should remove file _only_ if it can be recovered with the same state as it was before git-rm. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html