Re: [PATCH v2 2/2] remote.c: remove BUG in show_push_unqualified_ref_name_error()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 04, 2025 at 11:24:40PM -0700, Denton Liu wrote:
> When "git push <remote> <src>:<dst>" does not spell out the
> destination side of the ref fully, and when <src> is not given
> as a reference but an object name, the code tries to give advice
> messages based on the type of that object.
> 
> The type is determined by calling odb_read_object_info() and
> signalled by its return value.  The code however reported a
> programming error with BUG() when this function said that there
> is no such object, which happens when the object name is given
> as a full hexadecimal (if the object name is given as a partial
> hexadecimal or an non-existing ref, the function would have died
> without returning, so this BUG() wouldn't have triggered).  This
> is wrong.  It is an ordinary end-user mistake to give an object
> name that does not exist and treated as such.

Yup, makes sense.

> diff --git a/remote.c b/remote.c
> index e965f022f1..4ad20110e9 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1218,8 +1218,7 @@ static void show_push_unqualified_ref_name_error(const char *dst_value,
>  			 "'%s:refs/tags/%s'?"),
>  		       matched_src_name, dst_value);
>  	} else {
> -		BUG("'%s' should be commit/tag/tree/blob, is '%d'",
> -		    matched_src_name, type);
> +		advise(_("The <src> part of the refspec is an oid that doesn't exist.\n"));

I think we should rather say "object ID", as "oid" is an abbreviation
that might not be immediately obvious to the user. Also, should we
continue to mention the object ID? Otherwise it might be hard for the
user to figure out which object ID doesn't exist in case they pass
multiple refspecs.

Patrick




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux