Jeff King [off-list ref] 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.
On Mon, Jul 02, 2007 at 09:47:33PM -0700, Junio C Hamano wrote:
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
Ah, makes sense (if such a thing can be said about CVS behavior).
quoted
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
It depends on how we want to define "lost" data. In many cases, we are
protecting against losing content that will still be available until the
next git-prune. Should our safety valve protect against that case, or
should it not? We are totally inconsistent.
The main one for --cached, of course, is when that content exists _only_
in the index, but no longer in the working tree (!A A N or !A A B). You
really should be using regular git-rm (in the first case, since you are
saying "I don't want this file anymore") or git-add (throw out the old
data, use my new version).
OTOH, clearly git-add can "lose" data in this way as well, since a
"modify, git-add, modify, git-add" will "lose" any reference to the
index state after the first add. So maybe that is not worth worrying
about at all (in which case our safety valve is too strict in many
places).
We could also issue a warning when "losing" reference to data that is in
the object db, which would include the sha1; in that case, an immediate
"oops" could be rectified with git-show.
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.
How about:
git-add foo
echo changes >>foo
# oops, I don't want to commit foo just yet
git-rm --cached foo
but in that case, maybe the user doesn't actually _care_ about that
intermediate state of 'foo'.
-Peff