Re: Behavior of git rm

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

Jeff King [off-list ref] writes:

quoted

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