git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
++ :

  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).