David Turner <[email protected]> wrote:
> It appears that get_oid_with_context calls into get_short_oid for that
> case, and get_short_oid returns SHORT_NAME_AMBIGUOUS, which is -2. We
> treat that as DANGLING_SYMLINK, which also seems to have the value -2.
> So, it's an ambiguity in ambiguity resolution.
>
> Fix attached.
Thanks for the quick response. Unfortunately, the patch makes
the situation worse for me...
> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index 2ca56fd086..f2344b199f 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -380,7 +380,7 @@ static void batch_one_object(const char *obj_name,
> {
> struct object_context ctx;
> int flags = opt->follow_symlinks ? GET_OID_FOLLOW_SYMLINKS : 0;
> - enum follow_symlinks_result result;
> + enum get_oid_result result;
>
> result = get_oid_with_context(obj_name, flags, &data->oid, &ctx);
> if (result != FOUND) {
> @@ -388,6 +388,9 @@ static void batch_one_object(const char *obj_name,
> case MISSING_OBJECT:
> printf("%s missing\n", obj_name);
> break;
> + case SHORT_NAME_AMBIGUOUS:
> + /* We've already printed the ambiguous message */
> + break;
Because the message about ambiguity only goes to stderr.
Something needs to go to stdout, or else the reader process
would hang forever.
I've already updated my code[1] to work around "dangling",
but maybe printing "ambiguous" similar to the "missing" message
would be appropriate? Something like:
case SHORT_NAME_AMBIGUOUS:
printf("%s ambiguous\n", obj_name);
break;
(Along with a manpage update)
[1] new stuff for public-inbox on the way :>
