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

Jeff King [off-list ref] 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.