git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: <git@vger.kernel.org>,  Jacob Keller <jacob.keller@gmail.com>
Subject: Re: [PATCH v3 4/4] diff --no-index: support limiting by pathspec
Date: Tue, 20 May 2025 09:30:10 -0700	[thread overview]
Message-ID: <xmqqy0uri6st.fsf@gitster.g> (raw)
In-Reply-To: <20250520000125.2162144-5-jacob.e.keller@intel.com> (Jacob Keller's message of "Mon, 19 May 2025 17:01:25 -0700")

Jacob Keller <jacob.e.keller@intel.com> writes:

> The git diff --no-index mode does not support pathspecs, and cannot
> limit the diff output in this way. Other diff programs such as GNU
> difftools have options for excluding paths based on a pattern match.

True.

> However, using git diff as a diff replacement has several advantages
> over many popular diff tools, including coloring moved lines, rename
> detections, and similar.

I said this when we introduced "--no-index", but back when "git" was
still young, it would have helped a lot wider developer populations
if we didn't do "git diff --no-index" and instead donated these
features to "many popular diff tools".  We however chose to be lazy
and selfish---those who want to use these features are better off
installing "git" even if they are not using it for version control,
only to use it as "better diff".

People are still welcome to add "coloring moved lines, rename
detections and similar" to "many popular diff tools", but given that
"git" has become fairly popular and widely used, it may not matter
all that much any more that we were lazy and selfish ;-).

> Teach git diff --no-index how to handle pathspecs to limit the
> comparisons. This will only be supported if both provided paths are
> directories.

Good.  If you are giving only two files, pathspec limiting would not
make much sense.  If you are giving a file and a directory, lazily
give only F and D to compare F with D/F, that is essentially giving
only two files F and D/F, so pathspec limiting would not make much
sense, either.  pathspec limited comparison would make sense only
when you are talking about two sets of files.

> However, if we always passed DO_MATCH_LEADING_PATHSPEC, then we will
> incorrectly match in certain cases such as matching 'a/c' against
> ':(glob)**/d'. The match logic will see that a matches the leading part
> of the **/ and accept this even tho c doesn't match. The trick seems to
> be setting both DO_MATCH_LEADING_PATHSPEC and DO_MATCH_DIRECTORY when
> checking directories, but set neither of them when checking files.

Sounds sensible.

> Some other gotchas and open questions:
>
>  1) pathspecs must all come after the first two path arguments, you
>     can't re-arrange them to come first. I'm treating them sort of like
>     the treeish arguments to git diff-tree.

Exactly.  "git diff" proper is about comparing two sets of files,
either comparing two tree-ishes "git diff master next", comparing a
tree-ish and the index "git diff --cached HEAD", comparing a
tree-ish and the working tree files "git diff HEAD", or comparing
the index and the working tree files "git diff".  It is a natural
extension that "git --no-index dirA dirB" compares contents of the
two directories.  In all of these forms, it is common that the
comparison can be pathspec limited by giving pathspec elements as
the command line arguments at the end.

>  2) The pathspecs are interpreted relative to the provided paths, and
>     thus will always need to be specified as relative paths, and will be
>     interpreted as relative to the root of the search for each path
>     separately.

Yes, that is not anything new or something we need to point out as
if it is any different from the "normal" pathspec.

>  3) negative pathspecs have to be fully qualified from the root, i.e.
>     ':(exclude)file' will only exclude 'a/file' and not 'a/b/file'
>     unless you also use '(glob)' or similar. I think this matches the
>     other pathspec support, but I an not 100% sure.

I think that is correct "git ls-files :(exclude)po" does not exclude
git-gui/po, for example.

> -`git diff [<options>] --no-index [--] <path> <path>`::
> +`git diff [<options>] --no-index [--] <path> <path> [<pathspec>...]`::

This is a bit unfortunate.  The disambiguating "--" should ideally
be between the "things to be compared" and the pathspec, as the
former corresponds to <rev> in the normal "git diff" invocation.

> +	... If both
> +	paths point to directories, additional pathspecs may be
> +	provided. These will limit the files included in the
> +	difference. All such pathspecs must be relative as they
> +	apply to both sides of the diff.

"as they" -> "and they"?

> +test_expect_success 'diff --no-index with pathspec' '
> +	test_expect_code 1 git diff --no-index a b 1 >actual &&
> +	cat >expect <<-EOF &&
> +	diff --git a/a/1 b/a/1
> +	deleted file mode 100644
> +	index d00491f..0000000
> +	--- a/a/1
> +	+++ /dev/null
> +	@@ -1 +0,0 @@
> +	-1
> +	EOF
> +	test_cmp expect actual
> +'

If you use --name-only or --name-status would the test become
simpler?

> +
> +test_expect_success 'diff --no-index with pathspec no matches' '
> +	test_expect_code 0 git diff --no-index a b missing
> +'

OK.

> +test_expect_success 'diff --no-index with negative pathspec' '
> +	test_expect_code 1 git diff --no-index a b ":!2" >actual &&
> +	cat >expect <<-EOF &&
> +	diff --git a/a/1 b/a/1
> +	deleted file mode 100644
> +	index d00491f..0000000
> +	--- a/a/1
> +	+++ /dev/null
> +	@@ -1 +0,0 @@
> +	-1
> +	EOF
> +	test_cmp expect actual
> +'

OK.

All other tests also look sensible.

Thanks.

  reply	other threads:[~2025-05-20 16:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20  0:01 [PATCH v3 0/4] diff: add pathspec support to --no-index Jacob Keller
2025-05-20  0:01 ` [PATCH v3 1/4] prefix_path: support prefixes not ending in trailing slash Jacob Keller
2025-05-20 14:35   ` Junio C Hamano
2025-05-20 22:34     ` Jacob Keller
2025-05-20  0:01 ` [PATCH v3 2/4] pathspec: expose match_pathspec_with_flags Jacob Keller
2025-05-20 14:39   ` Junio C Hamano
2025-05-20 22:38     ` Jacob Keller
2025-05-20  0:01 ` [PATCH v3 3/4] pathspec: add flag to indicate operation without repository Jacob Keller
2025-05-20 15:13   ` Junio C Hamano
2025-05-20 22:42     ` Jacob Keller
2025-05-21 23:05     ` Jacob Keller
2025-05-20  0:01 ` [PATCH v3 4/4] diff --no-index: support limiting by pathspec Jacob Keller
2025-05-20 16:30   ` Junio C Hamano [this message]
2025-05-20 22:45     ` Jacob Keller
2025-05-20 22:47     ` 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=xmqqy0uri6st.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jacob.keller@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.
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).