Jeff King <peff@xxxxxxxx> writes:
> H I W | ok? | why?
> ---------------------------------------------------
> N A N | ? | currently ok, but 'A' recoverable only through fsck
> A B N | ? | currently ok, but 'B' recoverable only through fsck
These were explicitly done per request from git-rm users (myself
not one of them) who wanted to:
rm the-file
git rm the-file
sequence not to barf. I suspect they were from CVS background
who are used to the SCM that complains if you still have the
file in the working tree when you say "scm rm".
I would not mind requiring -f for these cases.
> With --cached on, it is a little different:
>
> H I W | ok? | why?
> ---------------------------------------------------
> N A N | ? | currently ok, but 'A' recoverable only through fsck
> N A A | ? | currently not ok, but 'A' still available in W
> 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 B | ? | currently not ok, but 'B' still available in W
I personally do not think we would need any safety check for
"git rm --cached", as it does not touch the working tree. If
one cares about the differences among three states, one would
not issue "rm --cached" anyway. The only reason "rm --cached"
is used is because one _knows_ that any blob should not exist at
that path in the index.
-
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
