On Thu, Sep 21, 2023 at 12:04:11PM -0700, Junio C Hamano wrote:

Patrick Steinhardt [off-list ref] writes:

[snip]

quoted

Signed-off-by: Patrick Steinhardt <redacted>
Reported-by: Christian Couder <redacted>
---
 Documentation/rev-list-options.txt |  6 +++++-
 revision.c                         | 10 +++++-----
 t/t6017-rev-list-stdin.sh          | 21 +++++++++++++++++++++
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index a4a0cb93b2..9bf13bac53 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt

@@ -151,6 +151,8 @@ endif::git-log[]
 --not::
 	Reverses the meaning of the '{caret}' prefix (or lack thereof)
 	for all following revision specifiers, up to the next `--not`.
+	When used on the command line before --stdin, the revisions passed
+	through stdin will not be affected by it.

Do we also need to say "when read from --stdin, the revisions passed
on the command line are not affected" as well?  I know you have it
where you explian "--stdin" in the next hunk, but since you are
adding one-half of the interaction, it may be less confusing to also
mention the other half at the same time.

Doesn't hurt to make this more explicit as well, yes. I'll send a v2
that adds this bit.

Thanks!

Patrick

quoted

@@ -240,7 +242,9 @@ endif::git-rev-list[]
 	them from standard input as well. This accepts commits and
 	pseudo-options like `--all` and `--glob=`. When a `--` separator
 	is seen, the following input is treated as paths and used to
-	limit the result.
+	limit the result. Flags like `--not` which are read via standard input
+	are only respected for arguments passed in the same way and will not
+	influence any subsequent command line arguments.

Other than that, looking good, and the changes to the code look all
sensible.

Thanks.