Re: Mismatched HEAD default behavior from git log

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2020, 19:40 UTC
Message-ID: <xmqq8se21pl1.fsf@gitster.c.googlers.com>
In-Reply-To: <CAGyf7-G_ciVpgvvOiH1Fq9kNuWunCpM1fhv3ao_RMXBB0K=HMA@mail.gmail.com>

Bryan Turner <bturner@atlassian.com> writes:

Show 14 quoted lines

> It appears the way --stdin processes input discards nonexistent
> commits before the machinery that decides whether you provided any
> revs or not runs, and so if every --stdin rev is discarded then you
> get the default HEAD. If you provide them via the command line,
> though, then it seems like they're discarded later and you don't get a
> default.
>
> I'm not sure whether this is intentional or not (certainly I don't see
> it anywhere in the git log documentation for --ignore-missing or
> --stdin), but it results in a behavior mismatch that's impossible to
> reconcile without requiring extra git processes. I can't always
> provide HEAD since, if multiple revs are supplied, if any revs exist
> then HEAD would not be included regardless of whether the revs were
> supplied via the command line or --stdin.

As the intent for adding the "--stdin" option to any subcommand has always been "we may need to feed many many things, that may bust the command line length limit, hence we let you feed these things from the standard input, but otherwise there should be no change in behaviour or semantics", when the behaviour of command line and "--stdin" differ, it is a bug in the latter.