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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 5, 2008, 08:48 UTC
Message-ID: <7vwsoho8t4.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080305043319.GA9074@sigill.intra.peff.net>

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.