Re: [PATCH DONOTAPPLY 5/4] revision: let --stdin set rev_input_given
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 3, 2017, 15:59 UTC
- Message-ID
- <xmqq3798r6ai.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170802223416.gwiezhbuxbdmbjzx@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 12 quoted lines
> 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?
Show 6 quoted lines
> 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/nullIf 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.