From: Junio C Hamano <gitster@pobox.com>
To: Josip Sokcevic <sokcevic@google.com>
Cc: jonathantanmy@google.com, git@vger.kernel.org, git@jeffhostetler.com
Subject: Re: [PATCH v3] diff-lib: Fix check_removed when fsmonitor is on
Date: Tue, 12 Sep 2023 10:07:25 -0700 [thread overview]
Message-ID: <xmqqfs3jpbg2.fsf@gitster.g> (raw)
In-Reply-To: <CAJiyOijMvqK184wFgoXFyX5kmURkX3k2OmuiBpArikj26iHpMA@mail.gmail.com> (Josip Sokcevic's message of "Mon, 11 Sep 2023 20:03:47 -0700")
Josip Sokcevic <sokcevic@google.com> writes:
> Yes, I agree we should optimize this in a follow up. One thing I'm not
> sure about is if we should try to construct `struct stat` using
> `cache_index`, or we should check for `CE_FSMONITOR_VALID` in a way
> that `stat` would no longer be needed for those code paths.
Good point.
It seems to be entirely doable, even though the stench from the
abstraction layer violation may be horrible.
ie_match_stat(), which is called by match_stat_with_submodule(),
does pay attention to CE_FSMONITOR_VALID bit, so none of the members
of struct stat matters when the bit is set. But the bit is not set,
all members that fill_stat_data() and ce_match_stat_basic() care
about do matter. Other code that follows callers of check_removed()
do care about at least .st_mode member, and I suspect that in the
current code .st_mode is the only member that gets looked at.
So after all, I think your original "fix" was correct, but it took
us some time to figure out why it was, which means we would want to
explain it in the log message for developers who would want to touch
the same area in the future.
Thanks.
next prev parent reply other threads:[~2023-09-12 17:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 0:56 Strange diff-index with fsmonitor, submodules Jonathan Tan
2023-08-29 1:20 ` Junio C Hamano
2023-08-29 12:45 ` Jeff Hostetler
2023-08-29 16:57 ` Jeff Hostetler
2023-08-29 17:01 ` Jonathan Tan
2023-09-06 6:02 ` [PATCH] [diff-lib] Fix check_removed when fsmonitor is on Josip Sokcevic
2023-09-06 20:37 ` Jonathan Tan
2023-09-07 17:01 ` [PATCH v2] diff-lib: " Josip Sokcevic
2023-09-07 17:22 ` Jonathan Tan
2023-09-07 18:07 ` Junio C Hamano
2023-09-07 23:08 ` Josip Sokcevic
2023-09-08 15:00 ` Junio C Hamano
2023-09-11 17:09 ` [PATCH v3] " Josip Sokcevic
2023-09-11 22:53 ` Junio C Hamano
2023-09-12 3:03 ` Josip Sokcevic
2023-09-12 17:07 ` Junio C Hamano [this message]
2023-09-14 22:39 ` Josip Sokcevic
2023-09-18 16:35 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqfs3jpbg2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
--cc=sokcevic@google.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.
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).