git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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/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.
Previous: Jeff KingNext: Jeff King
Message 11 of 13 in “handling empty inputs in the revision machinery”
  1. 0/4 handling empty inputs in the revision machineryJeff King, Aug 2, 2017
  2. 1/4 t6018: flesh out empty input/output rev-list testsJeff King, Aug 2, 2017
  3. 2/4 revision: add rev_input_given flagJeff King, Aug 2, 2017
  4. Junio C HamanoAug 2, 2017
  5. Jeff KingAug 2, 2017
  6. 3/4 rev-list: don't show usage when we see empty ref patternsJeff King, Aug 2, 2017
  7. 4/4 revision: do not fallback to default when rev_input_given is setJeff King, Aug 2, 2017
  8. Junio C HamanoAug 2, 2017
  9. Stefan BellerAug 2, 2017
  10. 5/4 revision: let --stdin set rev_input_givenJeff King, Aug 2, 2017
  11. Junio C HamanoAug 3, 2017
  12. Jeff KingAug 3, 2017
  13. Junio C HamanoAug 2, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.