On Wed, Mar 05, 2008 at 12:48:39AM -0800, Junio C Hamano wrote: > 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"). Well, if you are comfortable, then I have no real objection. I just wanted to raise the point since I didn't really know how widely and in what way --default was being used. > 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. Sure, that is reasonable. The syntax is a bit ugly. Maybe just set an ignore_default_errors flag to '1', and then if --default is specified on the commandline, set it to '0'. The behavior should be identical for all external scripts, and we can audit the internal uses. But given your 'master' example above, I think you would actually want it to be treated in the same way; if master doesn't exist, it is empty. IOW, it is the "defaultness" which makes one want to ignore errors. > > 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. True. Although considering your 'master' example above, it is not just "symref whose target doesn't exist", but "ref does not exist". In either case (internal HEAD or explicit --default) I think something like "ref exists but is corrupted" is something you would expect git to note. Hrm. Thinking about it a bit more, what should be done with a --default like "HEAD^^"? It currently works fine, but parsing it down to "HEAD" requires the magic of get_sha1_with_mode. I think anyone using anything but an unadorned refname for --default is probably insane, though. Would it be acceptable to formally disallow it? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
