Subject: Re: [PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

From: Junio C Hamano <[email-masked]>
Date: Tue, 07 Jan 2014 11:38:15 -0800

Jeff King <[email-masked]> writes:

> On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote:
>
>> Jeff King <[email-masked]> writes:
>> 
>> > Alternatively, I guess "cat-file
>> > --batch" could just turn off warn_ambiguous_refs itself.
>> 
>> Sounds like a sensible way to go, perhaps on top of this change?
>
> The downside is that we would not warn about ambiguous refs anymore,
> even if the user was expecting it to. I don't know if that matters much.

That is true already with or without Brodie's change, isn't it?
With warn_on_object_refname_ambiguity, "cat-file --batch" makes us
ignore core.warnambigousrefs setting.  If we redo 25fba78d
(cat-file: disable object/refname ambiguity check for batch mode,
2013-07-12) to unconditionally disable warn_ambiguous_refs in
"cat-file --batch" and get rid of warn_on_object_refname_ambiguity,
the end result would be the same, no?

> I kind of feel in the --batch situation that it is somewhat useless (I
> wonder if "rev-list --stdin" should turn it off, too).

I think doing the same as "cat-file --batch" in "rev-list --stdin"
makes sense.  Both interfaces are designed to grok extended SHA-1s,
and full 40-hex object names could be ambiguous and we are missing
the warning for them.

Or are you wondering if we should revert 25fba78d, apply Brodie's
change to skip the ref resolution whose result is never used, and
tell people who want to use "cat-file --batch" (or "rev-list
--stdin") to disable the ambiguity warning themselves?