Jeff King <p...@peff.net> writes:
> +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.
> +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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
