From: "Torsten Bögershausen" <tboegi@web.de>
To: Chandra Pratap via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Chandra Pratap <chandrapratap376@gmail.com>,
Chandra Pratap <chandrapratap3519@gmail.com>
Subject: Re: [PATCH v2] Teach git apply to respect core.fileMode settings
Date: Tue, 19 Dec 2023 21:46:12 +0100 [thread overview]
Message-ID: <20231219204612.GA26266@tb-raspi4> (raw)
In-Reply-To: <pull.1620.v2.git.1703010646036.gitgitgadget@gmail.com>
On Tue, Dec 19, 2023 at 06:30:45PM +0000, Chandra Pratap via GitGitGadget wrote:
> From: Chandra Pratap <chandrapratap3519@gmail.com>
>
Thanks for working on this, some small nit-picks inline.
> When applying a patch that adds an executable file, git apply
> ignores the core.fileMode setting (core.fileMode in git config
> specifies whether the executable bit on files in the working tree
> should be honored or not) resulting in warnings like:
>
> warning: script.sh has type 100644, expected 100755
>
> even when core.fileMode is set to false, which is undesired. This
> is extra true for systems like Windows, which don't rely on "lsat()".
Small typo here: lsat() should be lstat(). But being nit-picking (and simplifying):
Windows does not provide an implementation, so Git for Windows does it's own,
which currently does not implement the x-bit(s).
In short: The ', which don't rely on "lsat()' could probably just removed.
>
> Fix this by inferring the correct file mode from the existing
> index entry when core.filemode is set to false. The added
> test case helps verify the change and prevents future regression.
Another nit-pick, sorry for that, I try to convince everybody to not
use "added".
So may be
Add a test case that verifies the change and prevents future regression.
>
> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmail.com>
> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com>
> ---
> apply: make git apply respect core.fileMode settings
>
> Closes issue #1555 on GitHub.
>
[]
>
>
> apply.c | 8 ++++++--
> t/t4129-apply-samemode.sh | 25 +++++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/apply.c b/apply.c
> index 3d69fec836d..58f26c40413 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -3778,8 +3778,12 @@ static int check_preimage(struct apply_state *state,
> return error_errno("%s", old_name);
> }
>
> - if (!state->cached && !previous)
> - st_mode = ce_mode_from_stat(*ce, st->st_mode);
> + if (!state->cached && !previous) {
> + if (!trust_executable_bit)
> + st_mode = *ce ? (*ce)->ce_mode : patch->old_mode;
> + else
> + st_mode = ce_mode_from_stat(*ce, st->st_mode);
> + }
>
> if (patch->is_new < 0)
> patch->is_new = 0;
> diff --git a/t/t4129-apply-samemode.sh b/t/t4129-apply-samemode.sh
> index e7a7295f1b6..73fc472b246 100755
> --- a/t/t4129-apply-samemode.sh
> +++ b/t/t4129-apply-samemode.sh
> @@ -101,4 +101,29 @@ test_expect_success POSIXPERM 'do not use core.sharedRepository for working tree
> )
> '
>
> +test_expect_success 'ensure git apply respects core.fileMode' '
Small nit-pick:
The "ensure" is probably not needed, all tests ensure something.
> + test_config core.fileMode false &&
> + echo true >script.sh &&
> + git add --chmod=+x script.sh &&
> + git ls-files -s script.sh | grep "^100755" &&
> + test_tick && git commit -m "Add script" &&
> + git ls-tree -r HEAD script.sh | grep "^100755" &&
> +
> + echo true >>script.sh &&
> + test_tick && git commit -m "Modify script" script.sh &&
> + git format-patch -1 --stdout >patch &&
> + grep "index.*100755" patch &&
> +
> + git switch -c branch HEAD^ &&
> + git apply --index patch 2>err &&
> + ! grep "has type 100644, expected 100755" err &&
This feels somewhat volatile against future changes.
grep-ing for things that are not there, without verifying
that they are there, without this patch.
On my test system, there is no message at all, so a
test_must_be_empty err &&
feels more "stable".
> + git restore -S script.sh && git restore script.sh &&
> +
> + git apply patch 2>err &&
> + ! grep "has type 100644, expected 100755" err &&
> +
> + git apply --cached patch 2>err &&
> + ! grep "has type 100644, expected 100755" err
> +'
> +
> test_done
next prev parent reply other threads:[~2023-12-19 20:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 14:09 [PATCH] Teach git apply to respect core.fileMode settings Chandra Pratap via GitGitGadget
2023-12-18 18:04 ` Junio C Hamano
2023-12-18 18:10 ` Junio C Hamano
2023-12-19 17:07 ` Chandra Pratap
2023-12-19 18:30 ` [PATCH v2] " Chandra Pratap via GitGitGadget
2023-12-19 20:46 ` Torsten Bögershausen [this message]
2023-12-19 22:21 ` Junio C Hamano
2023-12-20 10:08 ` [PATCH v3] " Chandra Pratap via GitGitGadget
2023-12-24 13:42 ` Johannes Schindelin
2023-12-26 17:35 ` Junio C Hamano
2023-12-26 19:18 ` Johannes Schindelin
2023-12-26 20:10 ` Junio C Hamano
2023-12-26 20:58 ` Junio C Hamano
2023-12-26 21:35 ` Junio C Hamano
2023-12-26 23:32 ` [PATCH v4 0/3] apply with core.filemode=false Junio C Hamano
2023-12-26 23:32 ` [PATCH v4 1/3] apply: ignore working tree filemode when !core.filemode Junio C Hamano
2023-12-26 23:32 ` [PATCH v4 2/3] apply: correctly reverse patch's pre- and post-image mode bits Junio C Hamano
2023-12-26 23:32 ` [PATCH v4 3/3] apply: code simplification Junio C Hamano
2024-02-07 22:15 ` [PATCH v4 0/3] apply with core.filemode=false Junio C Hamano
2024-02-18 22:38 ` Johannes Schindelin
2024-02-19 21:24 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231219204612.GA26266@tb-raspi4 \
--to=tboegi@web.de \
--cc=chandrapratap3519@gmail.com \
--cc=chandrapratap376@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).