On Mon, Jul 02, 2007 at 11:20:59PM +0200, Christian Jaeger wrote: > So there's no -f flag in normal git-rm usage. It thus has a different > meaning, namely "force the operation pair of removing from index and > unlinking", not "force this operation also onto the checked out files" > as is the case with cogito. Yes, git-rm is used in several situations, and the idea is that it should behave safely in all situations; that is, without -f you can't delete any data that can't be recovered from your history (but maybe that means we shouldn't suggest -f in so cavalier a fashion). Each file has three "states" that we care about: in the HEAD (H), in the index (I), and in the working tree (W). Let's say you call 'git-rm'. Here's a table of possibilities (A is some content "A", B is some content not equal to "A", and N is "non-existant"): H I W | ok? | why? --------------------------------------------------- * N * | no | file is not tracked N A N | ? | currently ok, but 'A' recoverable only through fsck N A A | no | 'A' recoverable only through fsck N A B | no | local modification 'B' would be lost A A N | yes | 'A' recoverable through history A A A | yes | 'A' recoverable through history A A B | no | local modification 'B' would be lost A B N | ? | currently ok, but 'B' recoverable only through fsck A B A | no | 'B' recoverable only through fsck A B B | no | 'B' recoverable only through fsck B * * | | equivalent to H=A With --cached on, it is a little different: H I W | ok? | why? --------------------------------------------------- * N * | no | file is not tracked N A N | ? | currently ok, but 'A' recoverable only through fsck N A A | ? | currently not ok, but 'A' still available in W N A B | no | 'A' recoverable only through fsck A A N | yes | 'A' recoverable through history A A A | yes | 'A' recoverable through history or working tree A A B | ? | currently not ok, but 'A' still available in H A B N | ? | currently ok, but 'B' recoverable only through fsck A B A | no | 'B' recoverable only through fsck A B B | ? | currently not ok, but 'B' still available in W B * * | | equivalent to H=A So it looks like our safety valve is a bit overbearing in a few situations, and still misses some situations where data has to be pulled out of the database with git-fsck. I think if we actually spell out these possible states in the code, we can get more accurate behavior, but also more accurate error messages. I will try to work up a patch. -Peff - 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
