git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Chandra Pratap via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Torsten Bögershausen" <tboegi@web.de>,
	"Chandra Pratap" <chandrapratap376@gmail.com>,
	"Chandra Pratap" <chandrapratap3519@gmail.com>
Subject: Re: [PATCH v3] Teach git apply to respect core.fileMode settings
Date: Tue, 26 Dec 2023 13:35:49 -0800	[thread overview]
Message-ID: <xmqqcyusfxze.fsf@gitster.g> (raw)
In-Reply-To: <xmqqv88kfzpr.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 26 Dec 2023 12:58:24 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>> As pointed out e.g. by t2016.3(git checkout -p), if the patch is to be
>>> applied in reverse (`git apply -R`), then the `old_mode` is actually 0,
>>> and we must use `new_mode` instead.
>>
>> Good finding.
>
> Hmph, this is puzzling and I spoke way before I understand why/how
> the fixup patch works X-<.
>
> The caller of check_preimage(), check_patch(), should happen only
> after reverse_patches() swapped old and new names and modes in
> apply_patch(), so at this point, we should be able to consistently
> use old_mode for checking, shouldn't we, even with "-R"?

I think I figured it out.  When we parse an incoming patch, unless
the patch is about changing the mode, we only fill old_mode (e.g.,
follow the callflow from gitdiff_index() -> gitdiff_oldmode() ->
parse_mode_line() to see how this is done).  In check_patch(), which
is the caller of check_preimage() in question, there are lines that
propagate old_mode to new_mode (because unfilled new_mode can come
only because there was no mode change), but that happens much later
after check_preimage() was called and returned.

I also suspect that this copying from old to new should be done much
earlier, after parse_chunk() finds out the (old)mode by calling
find_header(), and by doing so, you wouldn't have been hit by the
"-R makes old_mode 0" because both sides would be correctly filled
before we call reverse_patches() gets called.  But I haven't traced
all existing codepaths to see if such a change has unintended
consequences (e.g., somebody may incorrectly assuming that "old_mode
== new_mode == 100644" and "old_mode == 100644, new_mode == 0" mean
different things and acting differently).

In any case, I suspect that a better check is not about "are we
applying in reverse?", but more like the attached patch, i.e. if old
side is not filled, then we should pick up the other side.

 apply.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git c/apply.c w/apply.c
index 697ab2eb1f..5896056a69 100644
--- c/apply.c
+++ w/apply.c
@@ -3779,12 +3779,18 @@ static int check_preimage(struct apply_state *state,
 	}
 
 	if (!state->cached && !previous) {
-		if (!trust_executable_bit)
-			st_mode = *ce ? (*ce)->ce_mode :
-				(state->apply_in_reverse
-				 ? patch->new_mode : patch->old_mode);
-		else
+		if (!trust_executable_bit) {
+			if (*ce && !(*ce)->ce_mode)
+				BUG("ce_mode == 0 for path '%s'", old_name);
+			if (*ce)
+				st_mode = (*ce)->ce_mode;
+			else if (!patch->old_mode)
+				st_mode = patch->new_mode;
+			else
+				st_mode = patch->old_mode;
+		} else {
 			st_mode = ce_mode_from_stat(*ce, st->st_mode);
+		}
 	}
 
 	if (patch->is_new < 0)


  reply	other threads:[~2023-12-26 21:36 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
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 [this message]
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=xmqqcyusfxze.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=chandrapratap3519@gmail.com \
    --cc=chandrapratap376@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=tboegi@web.de \
    /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).