Re: Behavior of git rm

From: Jeff King <peff@peff.net>
Date: Apr 4, 2013, 19:02 UTC
Message-ID: <20130404190211.GA15912@sigill.intra.peff.net>
In-Reply-To: <7vli8z5xfr.fsf@alter.siamese.dyndns.org>

On Wed, Apr 03, 2013 at 10:35:52AM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Of the two situations, I think the first one is less likely to be
> > destructive (noticing that a file is already gone via ENOTDIR), as we
> > are only proceeding with the index deletion, and we end up not touching
> > the filesystem at all.
> 
> Nice to see sound reasoning.

Here's a patch series which I think covers what we've discussed.

  [1/3]: rm: do not complain about d/f conflicts during deletion
  [2/3]: t3600: test behavior of reverse-d/f conflict
  [3/3]: t3600: test rm of path with changed leading symlinks

The first one is the code change, and the rest just documents the cases we discussed.

The third one is a little subtle. For the most part is it just testing the normal "changed content requires --force" behavior of rm. But I think it is worth having because it also makes sure that after deleting "d/f" when "d" is a symlink to "e", that we do not remove the new directory "e" nor the symlink "d". I do not think this case was explicitly planned for, but it does do the right thing now, and given the subtlety, I'd rather somebody who changes it notice the breakage in the test suite.

-Peff