From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: jpinheiro <7jpinheiro@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 3/3] t3600: test rm of path with changed leading symlinks
Date: Thu, 4 Apr 2013 20:00:09 -0400 [thread overview]
Message-ID: <20130405000009.GA27775@sigill.intra.peff.net> (raw)
In-Reply-To: <7vd2u9g9bg.fsf@alter.siamese.dyndns.org>
On Thu, Apr 04, 2013 at 04:33:39PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So let's drop patch 3. Do we want instead to have an expect_failure
> > documenting the correct behavior?
>
> I think that is very much preferred.
Here's a replacement for patch 3, then. I wasn't sure if the
editorializing in the last 2 paragraphs should go in the commit message
or the cover letter; feel free to tweak as you see fit.
-- >8 --
Subject: [PATCH] t3600: document failure of rm across symbolic links
If we have a symlink "d" that points to a directory, we
should not be able to remove "d/f". In the normal case,
where "d/f" does not exist in the index, we already disallow
this, as we only remove things that git knows about in the
index. So for something like:
ln -s /outside/repo foo
git add foo
git rm foo/bar
we will properly produce an error (as there is no index
entry for foo/bar). However, if there is an index entry for
the path (e.g., because the movement is due to working tree
changes that have not yet been reflected in the index), we
will happily delete it, even though the path we delete from the
filesystem is not the same as the path in the index.
This patch documents that failure with a test.
While this is a bug, it should not be possible to cause
serious data loss with it. For any path that does not have
an index entry, we will complain and bail. For a path which
does have an index entry, we will do the usual up-to-date
content check. So even if the deleted path in the filesystem
is not the same as the one we are removing from the index,
we do know that they at least have the same content, and
that the content is included in HEAD.
That means the worst case is not the accidental loss of
content, but rather confusion by the user when a copy of a
file another part of the tree is removed. Which makes this
bug a minor and hard-to-trigger annoyance rather than a
data-loss bug (and hence the fix can be saved for a rainy
day when somebody feels like working on it).
Signed-off-by: Jeff King <peff@peff.net>
---
t/t3600-rm.sh | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index a2e1a03..0c44e9f 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -659,4 +659,32 @@ test_expect_success 'rm of file when it has become a directory' '
test_path_is_file d/f
'
+test_expect_success SYMLINKS 'rm across a symlinked leading path (no index)' '
+ rm -rf d e &&
+ mkdir e &&
+ echo content >e/f &&
+ ln -s e d &&
+ git add -A e d &&
+ git commit -m "symlink d to e, e/f exists" &&
+ test_must_fail git rm d/f &&
+ git rev-parse --verify :d &&
+ git rev-parse --verify :e/f &&
+ test -h d &&
+ test_path_is_file e/f
+'
+
+test_expect_failure SYMLINKS 'rm across a symlinked leading path (w/ index)' '
+ rm -rf d e &&
+ mkdir d &&
+ echo content >d/f &&
+ git add -A e d &&
+ git commit -m "d/f exists" &&
+ mv d e &&
+ 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
--
1.8.2.rc0.33.gd915649
next prev parent reply other threads:[~2013-04-05 0:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 14:50 Behavior of git rm jpinheiro
2013-04-03 15:58 ` Jeff King
2013-04-03 17:35 ` Junio C Hamano
2013-04-03 20:36 ` Jeff King
2013-04-04 19:02 ` Jeff King
2013-04-04 19:03 ` [PATCH 1/3] rm: do not complain about d/f conflicts during deletion Jeff King
2013-04-04 19:03 ` [PATCH 2/3] t3600: test behavior of reverse-d/f conflict Jeff King
2013-04-04 19:06 ` [PATCH 3/3] t3600: test rm of path with changed leading symlinks Jeff King
2013-04-04 19:42 ` Junio C Hamano
2013-04-04 19:55 ` Jeff King
2013-04-04 20:31 ` Junio C Hamano
2013-04-04 21:03 ` Jeff King
2013-04-04 23:12 ` Junio C Hamano
2013-04-04 23:29 ` Jeff King
2013-04-04 23:33 ` Junio C Hamano
2013-04-05 0:00 ` Jeff King [this message]
2013-04-05 4:59 ` Junio C Hamano
2013-04-05 5:04 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130405000009.GA27775@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=7jpinheiro@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).