Jeff King <[email protected]> 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.
