Re: [RFC] improve 'bad default revision' message for empty repo

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I'm not sure it's this easy. We're basically just ignoring the error
> return from get_sha1_with_mode, but do we really want to ignore _all_
> errors? Specifically, should "git log --default foobar" silently produce
> no commits?

Sure.

The thing is, nobody uses "--default" with random crap (i.e. risk of typo
running from the command line).  It is really about scripted use, and I can
guarantee majority of --default argument is HEAD, and in people's custom
scripts that are specially tailored for specific workflows, they would
use concrete commit object names that their workflow is built around as
convention (e.g. "alias.recent = git log --since=1.day --default master").

We could enhance the --default mechanism to say that its argument is
optional when it begins with a '?', and change our internal callers to
pass the equivalent of "--default ?HEAD", and keep the traditional die()
behaviour for non-optional defaults to catch breakages in end-user
scripts.

> I think a tighter rule that would accomplish the same thing is "if we
> resolve to a ref that is yet-to-be-born, then ignore." But unfortunately
> that information is lost deep within the bowels of get_sha1_with_mode.

Yes and no.  It is in the error path, so you can afford to redo resolving
the symref _after_ seeing get_sha1_with_mode() fail.