From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] diff --no-index: fix logic for paths ending in '/'
Date: Wed, 24 Sep 2025 15:03:25 -0700 [thread overview]
Message-ID: <xmqqecrvjyoi.fsf@gitster.g> (raw)
In-Reply-To: <20250924-jk-fix-no-index-path-with-slash-v1-1-6b2028c0de92@intel.com> (Jacob Keller's message of "Wed, 24 Sep 2025 13:57:15 -0700")
Jacob Keller <jacob.e.keller@intel.com> writes:
> If one of the two provided paths for git diff --no-index ends in a '/',
> a failure similar to the following occurs:
>
> $ git diff --no-index -- /tmp/ /tmp/ ':!'
> fatal: `pos + len' is too far after the end of the buffer
>
> This occurs because of an incorrect calculation of the skip lengths in
> diff_no_index(). The code wants to calculate the length of the string,
> but add one in case the string doesn't end with a slash.
>
> The method it uses is incorrect, as it always checks the trailing NUL
> character of the string. This will never be a '/', so we always add one.
> In the event that we *do* have a trailing slash, this will create an
> off-by-one length error later when using the skip value.
>
> The most straightforward fix would be to correct the skip1 and skip2
> lengths by using ends_with().
Meaning, "ah, this one ends with '/' so let's trim it and do
everything else the same as before"?
It certainly is how we usually handle regression fixes.
There were two topics that touched "git diff --no-index" in Git 2.51
timeframe, and the pathspec support was a new feature added by them,
so this is not exactly a regression.
> This fix might feel overly complex. We can drop this and just go with a
> simple ends_with() fix, but that leaves the needless strbuf_remove() in the
> read_directory_contents.
We can do it as a two-step patch series, which would allow us to
revert the more complex part relatively cleanly if it turns out to
break the cases that the current code handles fine. But as this is
a new feature in 2.51, it is OK to declare that the code never
worked correctly and we are making it right this time with a single
more ambitious patch.
Will queue. Thanks, both of you.
next prev parent reply other threads:[~2025-09-24 22:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 20:57 [PATCH] diff --no-index: fix logic for paths ending in '/' Jacob Keller
2025-09-24 22:03 ` Junio C Hamano [this message]
2025-09-24 22:18 ` Junio C Hamano
2025-09-24 22:24 ` Junio C Hamano
2025-09-25 17:17 ` Jacob Keller
2025-09-25 18:36 ` Junio C Hamano
2025-10-10 16:13 ` Junio C Hamano
2025-10-13 23:14 ` Jacob Keller
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=xmqqecrvjyoi.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=jacob.e.keller@intel.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).