From: Adam Dinwoodie <adam@dinwoodie.org>
To: Matheus Tavares <matheus.bernardino@usp.br>
Cc: Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] apply: don't use core.sharedRepository to create working tree files
Date: Sat, 19 Dec 2020 17:51:39 +0000 [thread overview]
Message-ID: <CA+kUOamDD_SDNLk3sPSwNAojrAAP+g38MjkfG4JMPRTGOVAKAQ@mail.gmail.com> (raw)
In-Reply-To: <3f0403b84ab06b9deb7c5c189792bebe1db586a7.1606866276.git.matheus.bernardino@usp.br>
This commit – eb3c027e17 ("apply: don't use core.sharedRepository to
create working tree files", 2020-12-01) – seems to have introduced a
new test failure in the Cygwin builds for v2.30.0-rc0, and which is
still present in rc1. I'm not quite sure I understand what the
expected behaviour here is, but I expect the issue is down to Cygwin's
slightly odd file permission handling.
To my surprise, the test fails if the worktree is under "/cygdrive",
but not if it's under "/home" within the Cygwin filesystem. I expect
this is some complexity with Cygwin's mount handling, but it's not a
failure mode I've seen before. I'm also going to follow up on the
Cygwin mailing list to see if the folk with a better understanding of
Cygwin's filesystem wrangling have a better understanding of what's
going on.
Extract from the relevant section of ./t4129-apply-samemode.sh -x
output, when run with that commit checked out, below:
expecting success of 4129.10 'do not use core.sharedRepository for
working tree files':
git reset --hard &&
test_config core.sharedRepository 0666 &&
(
# Remove a default ACL if possible.
(setfacl -k newdir 2>/dev/null || true) &&
umask 0077 &&
# Test both files (f1) and leading dirs (d)
mkdir d &&
touch f1 d/f2 &&
git add f1 d/f2 &&
git diff --staged >patch-f1-and-f2.txt &&
rm -rf d f1 &&
git apply patch-f1-and-f2.txt &&
echo "-rw-------" >f1_mode.expected &&
echo "drwx------" >d_mode.expected &&
test_modebits f1 >f1_mode.actual &&
test_modebits d >d_mode.actual &&
test_cmp f1_mode.expected f1_mode.actual &&
test_cmp d_mode.expected d_mode.actual
)
++ git reset --hard
HEAD is now at e950771 initial
++ test_config core.sharedRepository 0666
++ config_dir=
++ test core.sharedRepository = -C
++ test_when_finished 'test_unconfig '\''core.sharedRepository'\'''
++ test 0 = 0
++ test_cleanup='{ test_unconfig '\''core.sharedRepository'\''
} && (exit "$eval_ret"); eval_ret=$?; :'
++ git config core.sharedRepository 0666
++ setfacl -k newdir
++ true
++ umask 0077
++ mkdir d
++ touch f1 d/f2
++ git add f1 d/f2
++ git diff --staged
++ rm -rf d f1
++ git apply patch-f1-and-f2.txt
++ echo -rw-------
++ echo drwx------
++ test_modebits f1
++ ls -ld f1
++ sed -e 's|^\(..........\).*|\1|'
++ test_modebits d
++ ls -ld d
++ sed -e 's|^\(..........\).*|\1|'
++ test_cmp f1_mode.expected f1_mode.actual
++ test 2 -eq 2
++ eval 'diff -u' '"$@"'
+++ diff -u f1_mode.expected f1_mode.actual
--- f1_mode.expected 2020-12-19 16:50:20.169378700 +0000
+++ f1_mode.actual 2020-12-19 16:50:20.249126000 +0000
@@ -1 +1 @@
--rw-------
+-rw-rw-r--
++ test xf1_mode.expected = x-
++ test -e f1_mode.expected
++ test xf1_mode.actual = x-
++ test -e f1_mode.actual
++ return 1
error: last command exited with $?=1
++ test_unconfig core.sharedRepository
++ config_dir=
++ test core.sharedRepository = -C
++ git config --unset-all core.sharedRepository
++ config_status=0
++ case "$config_status" in
++ return 0
++ exit 1
++ eval_ret=1
++ :
next prev parent reply other threads:[~2020-12-19 17:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 15:23 Is git-am expected to honor core.sharedRepository? Matheus Tavares Bernardino
2020-12-01 17:58 ` Junio C Hamano
2020-12-01 23:45 ` [PATCH] apply: don't use core.sharedRepository to create working tree files Matheus Tavares
2020-12-02 0:21 ` Junio C Hamano
2020-12-19 17:51 ` Adam Dinwoodie [this message]
2020-12-19 18:12 ` Junio C Hamano
2020-12-19 18:59 ` Adam Dinwoodie
2020-12-19 18:32 ` Achim Gratz
2020-12-19 19:57 ` Adam Dinwoodie
2020-12-19 21:01 ` Achim Gratz
2020-12-22 22:24 ` Adam Dinwoodie
2020-12-22 22:49 ` Matheus Tavares Bernardino
2020-12-23 11:44 ` [PATCH] t4129: fix setfacl-related permissions failure Adam Dinwoodie
2021-01-09 15:06 ` Matheus Tavares Bernardino
2021-01-09 22:43 ` Junio C Hamano
2020-12-02 22:06 ` Is git-am expected to honor core.sharedRepository? Junio C Hamano
2020-12-03 1:44 ` Matheus Tavares Bernardino
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=CA+kUOamDD_SDNLk3sPSwNAojrAAP+g38MjkfG4JMPRTGOVAKAQ@mail.gmail.com \
--to=adam@dinwoodie.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=matheus.bernardino@usp.br \
/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).