On 9/24/2025 4:19 AM, Johannes Schindelin wrote:

Hi Jacob,

On Tue, 23 Sep 2025, Jacob Keller wrote:

quoted

On 9/23/2025 7:57 AM, Johannes Schindelin wrote:

quoted

However, this makes me wonder whether the logic itself is sound? It is
not immediately obvious to me why the `paths[0]` and `paths[1]` values
aren't matched against the pathspec yet their entirety is seemingly
skipped in `read_directory_contents()`?

I recall fiddling a lot to try and get this working. The idea here is
that fixup_paths does some conversions to handle the DWIM logic where a
"diff D F" becomes "diff D/F F". It returns true if both paths are
directories, so we only enter this block when both paths are
directories. (Which is required because we only support pathspec
limiting for directory differences).

I do wonder, after seeing that `read_directory_contents()` has to
(re-)construct a complete `strbuf` in every single invocation whether it
would make more sense to construct two `strbuf`s in `diff_no_index()` and
pass those along to `queue_diff()` _instead_ of `skip1`/`skip2`. The
`queue_diff()` function would then have to extend these
`strbuf`s as it already does with `buffer1`/`buffer2`.

That would avoid appending the same prefix only to remove it right away
(with a not exactly cheap `memmove()`) during every
`read_directory_contents()` invocation, too, in addition to allocating and
releasing those `strbuf`s over and over again.

Ciao,
Johannes

Something like that is probably simpler, but I'd need to figure out how
to do things right. I'm also not 100% certain how much it would save on
computation.

What we ultimately want to construct is the ability to figure out that
we're given A/B/C/D path and a filename E and a prefix A/B, we want to
get C/D/E for use with the pathspec matching logic.

So we still need to do some sort of prefix matching here, because
queue_diff gets (and indeed, needs) the full path for its main
non-pathspec purpose.