summaryrefslogtreecommitdiff
path: root/t/t4129-apply-samemode.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-01-09t4129: fix setfacl-related permissions failureLibravatar Adam Dinwoodie1-1/+1
When running this test in Cygwin, it's necessary to remove the inherited access control lists from the Git working directory in order for later permissions tests to work as expected. As such, fix an error in the test script so that the ACLs are set for the working directory, not a nonexistent subdirectory. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02apply: don't use core.sharedRepository to create working tree filesLibravatar Matheus Tavares1-0/+26
core.sharedRepository defines which permissions Git should set when creating files in $GIT_DIR, so that the repository may be shared with other users. But (in its current form) the setting shouldn't affect how files are created in the working tree. This is not respected by apply and am (which uses apply), when creating leading directories: $ cat d.patch diff --git a/d/f b/d/f new file mode 100644 index 0000000..e69de29 Apply without the setting: $ umask 0077 $ git apply d.patch $ ls -ld d drwx------ Apply with the setting: $ umask 0077 $ git -c core.sharedRepository=0770 apply d.patch $ ls -ld d drwxrws--- Only the leading directories are affected. That's because they are created with safe_create_leading_directories(), which calls adjust_shared_perm() to set the directories' permissions based on core.sharedRepository. To fix that, let's introduce a variant of this function that ignores the setting, and use it in apply. Also add a regression test and a note in the function documentation about the use of each variant according to the destination (working tree or git dir). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-27apply: check git diffs for invalid file modesLibravatar René Scharfe1-1/+15
An empty string as mode specification is accepted silently by git apply, as Vegard Nossum found out using AFL. It's interpreted as zero. Reject such bogus file modes, and only accept ones consisting exclusively of octal digits. Reported-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-26test: make FILEMODE a lazy prereqLibravatar Jonathan Nieder1-1/+0
This way, test authors don't need to remember to source lib-prereq-FILEMODE.sh before using the FILEMODE prereq to guard tests that rely on the executable bit being honored when checking out files. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18tests: Move FILEMODE prerequisite to lib-prereq-FILEMODE.shLibravatar Ævar Arnfjörð Bjarmason1-7/+1
Change the five tests that were all checking "git config --bool core.filemode" to use a new FILEMODE prerequisite in lib-prereq-FILEMODE.sh. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Skip tests that fail if the executable bit is not handled by the filesystemLibravatar Johannes Sixt1-6/+13
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-01-02builtin-apply: prevent non-explicit permission changesLibravatar Junio C Hamano1-0/+62
A git patch that does not change the executable bit records the mode bits on its "index" line. "git apply" used to interpret this mode exactly the same way as it interprets the mode recorded on "new mode" line, as the wish by the patch submitter to set the mode to the one recorded on the line. The reason the mode does not agree between the submitter and the receiver in the first place is because there is _another_ commit that only appears on one side but not the other since their histories diverged, and that commit changes the mode. The patch has "index" line but not "new mode" line because its change is about updating the contents without affecting the mode. The application of such a patch is an explicit wish by the submitter to only cherry-pick the commit that updates the contents without cherry-picking the commit that modifies the mode. Viewed this way, the current behaviour is problematic, even though the command does warn when the mode of the path being patched does not match this mode, and a careful user could detect this inconsistencies between the patch submitter and the patch receiver. This changes the semantics of the mode recorded on the "index" line; instead of interpreting it as the submitter's wish to set the mode to the recorded value, it merely informs what the mode submitter happened to have, and the presense of the "index" line is taken as submitter's wish to keep whatever the mode is on the receiving end. This is based on the patch originally done by Alexander Potashev with a minor fix; the tests are mine. Signed-off-by: Junio C Hamano <gitster@pobox.com>