Re: git-rm isn't the inverse action of git-add

From: Jeff King <peff@peff.net>
Date: Jul 3, 2007, 04:59 UTC
Message-ID: <20070703045948.GE4007@coredump.intra.peff.net>
In-Reply-To: <7vhcomt7oa.fsf@assigned-by-dhcp.cox.net>

On Mon, Jul 02, 2007 at 09:47:33PM -0700, Junio C Hamano wrote:

Show 5 quoted lines

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

Show 10 quoted lines

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