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). > > 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 - 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
