From: Junio C Hamano <gitster@pobox.com>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM
Date: Wed, 21 Sep 2016 13:47:42 -0700 [thread overview]
Message-ID: <xmqqa8f16kup.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqtwd986ml.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Wed, 21 Sep 2016 11:12:02 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> ... Comparing the index with the working tree using "status"
> is probably not how you would want to do so. A future breakage may
> cause the indexed blob name to change by mistake, and status would
> happily report difference but you would not notice its output is
> saying "Hey, they are different between the index and the working
> tree", while you are expecting ONLY the change in the executable bit.
In other words, how about doing it this way?
-- >8 --
From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 20 Sep 2016 08:18:25 +0200
Subject: [PATCH] t3700-add: do not rely on executable bit of the working tree file
A recently introduced test checks the result of 'git status' after
setting the executable bit on a file. This check does not yield the
expected result when the filesystem does not support the executable
bit.
The primary thing we care about is that a file added with --chmod=+x
has executable bit in the index, not that it is registered in the
index somehow differently from what is in the working tree, which
is what the "status" output tries to catch. Let's check what we
care about, i.e. the path is marked as an executable in the index.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t3700-add.sh | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 16ab2da..1a733bb 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -361,13 +361,11 @@ test_expect_success 'git add --chmod=[+-]x changes index with already added file
test_mode_in_index 100644 xfoo3
'
-test_expect_success 'file status is changed after git add --chmod=+x' '
- echo "AM foo4" >expected &&
+test_expect_success 'git add --chmod=[+-]x changes index with newly added file' '
echo foo >foo4 &&
git add foo4 &&
git add --chmod=+x foo4 &&
- git status -s foo4 >actual &&
- test_cmp expected actual
+ test_mode_in_index 100755 foo4
'
test_expect_success 'no file status change if no pathspec is given' '
--
2.10.0-515-g9036219
next prev parent reply other threads:[~2016-09-21 20:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 6:16 [PATCH tg/add-chmod+x-fix 1/2] t3700-add: create subdirectory gently Johannes Sixt
2016-09-20 6:18 ` [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM Johannes Sixt
2016-09-20 19:34 ` Thomas Gummerer
2016-09-21 18:12 ` Junio C Hamano
2016-09-21 20:47 ` Johannes Sixt
2016-09-21 20:47 ` Junio C Hamano [this message]
2016-09-21 20:58 ` Johannes Sixt
2016-09-21 21:12 ` Junio C Hamano
2016-09-22 5:06 ` Johannes Sixt
2016-09-22 21:01 ` Thomas Gummerer
2016-09-20 19:28 ` [PATCH tg/add-chmod+x-fix 1/2] t3700-add: create subdirectory gently Thomas Gummerer
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=xmqqa8f16kup.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=t.gummerer@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.