Re: [PATCH DONOTAPPLY 5/4] revision: let --stdin set rev_input_given

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> This patch makes "rev-list --stdin </dev/null" return an empty set.
> Which makes sense to me. But a side effect is that:
>
>   git log --stdin </dev/null
>
> now shows nothing (rather than HEAD). I think that's probably the right
> thing. But:
>
>   (echo --; echo t) | git log --stdin
>
> no longer defaults to HEAD. Which maybe people would see as a
> regression. I could see arguments either way.

Yeah, thanks for thinking this through.  I do think this would be a
regression.  On the other hand,

    (printf "%s\n" --tags=no-such -- t) | git log --stdin

should not default to HEAD and show nothing, I would think.

So if we wanted to do the "--stdin" thing properly, we probably need
to keep the "--stdin" option itself neutral wrt "did we get rev
input?"; instead, each input item that comes in from the standard
input stream would decide if the user wants us to fall back to the
default, perhaps?

> But this also breaks filter-branch (or at least a few of its tests),
> which really wants to do:
>
>   git rev-list --default HEAD --stdin <maybe-empty
>
> and traverse HEAD.

Hmph.  Do you mean the former should traverse from HEAD while the
latter should give us empty in the following two, because unlike
"log", "rev-list" does not do the "default to HEAD" thing if it is
not told to do so?

    git rev-list --default HEAD --stdin </dev/null
    git rev-list --stdin </dev/null

If so, I think the reasoning makes sense.

> I didn't dig enough to see if it's actually sane or
> not. The failing tests seem to be weird noop filters that our test
> script uses. But I'm worried it would break some real case, too.

Thanks.  Let's not rush things.  

The ones you sent for application 1-4/4 all are improvements.