Re: [PATCH 3/3] t3600: test rm of path with changed leading symlinks

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 4, 2013, 19:42 UTC
Message-ID: <7v6202hykh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130404190621.GA7484@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> +test_expect_success SYMLINKS 'replace dir with symlink to dir (same content)' '
> +	git reset --hard &&
> +	rm -rf d e &&
> +	mkdir e &&
> +	echo content >e/f &&
> +	ln -s e d &&
> +	git rm d/f &&
> +	test_must_fail git rev-parse --verify :d/f &&
> +	test -h d &&
> +	test_path_is_dir e
> +'

This does not check if e/f still exists in the working tree, and I suspect "git rm d/f" removes it.

If you do this:

	rm -fr d e
        mkdir e
        >e/f
        ln -s e d
        git add d/f

we do complain that d/f is beyond a symlink (meaning that all you can add is the symlink d that may happen to point at something).

Silent removal of e/f that is unrelated to the current project's tracked contents feels very wrong, and at the same time it looks to me that it is inconsistent with what we do when adding.

I need a bit more persuading to understand why it is not a bug, I think.

Show 13 quoted lines

> +test_expect_success SYMLINKS 'replace dir with symlink to dir (new content)' '
> +	git reset --hard &&
> +	rm -rf d e &&
> +	mkdir e &&
> +	echo changed >e/f &&
> +	ln -s e d &&
> +	test_must_fail git rm d/f &&
> +	git rev-parse --verify :d/f &&
> +	test -h d &&
> +	test_path_is_file e/f
> +'
> +
>  test_done