Re: [PATCH] revision: make pseudo-opt flags read via stdin behave consistently

[Taylor Blau <me@ttaylorr.com>]

On Mon, Sep 25, 2023 at 02:48:35PM +0200, Patrick Steinhardt wrote:
> > > 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.
> >
> > Hmmph. This seems to change the behavior introduced by 42cabc341c4. Am I
> > reading this correctly that tips on stdin with '--not --stdin' would not
> > be marked as UNINTERESTING?
> >
> > (Reading this back, there are a lot of double-negatives in what I just
> > wrote making it confusing for me at least. What I'm getting at here is
> > that I think `--not --stdin` should mark tips given via stdin as
> > UNINTERESTING).
>
> It does not change the behaviour, it only documents the current state
> such that it's at least spelled out somewhere.

Sorry, I must have been confused when writing this :-<. Looking at it
again, I agree that the current behavior is that "--not --stdin" treats
any tips given over stdin as INTERESTING, so this documentation is
consistent with that.

> > I wonder if we could instead do something like:
> >
> >   - inherit the current set of psuedo-opts when processing input over
> >     `--stdin`
> >   - allow pseudo-opts within the context of `--stdin` arbitrarily
> >   - prevent those psuedo-opts applied while processing `--stdin` from
> >     leaking over to subsequent command-line arguments.
> >
> > Here's one approach for doing that, where we make a copy of the current
> > set of flags when calling `read_revisions_from_stdin()` instead of
> > passing a pointer to the global state.
>
> That was indeed my first approach. But this change would break behaviour
> that was introduced with 42cabc341c4 (Teach rev-list an option to read
> revs from the standard input., 2006-09-05) almost 17 years ago. If we
> change it now then this is very likely to cause problems somewhere.

Per above, you're absolutely right. I think that the patch that you
proposed here LGTM.

Thanks,
Taylor