Subject: bug#79276: [PATCH] Pass remote name explicitly in bug-reference-try-setup-from-vc

From: Tassilo Horn <[email-masked]>
Date: Thu, 21 Aug 2025 20:51:25 +0200

André A. Gomes <[email-masked]> writes:

Hi André,

>> I don't think that's appropriate because bug-reference calls the
>> generic `vc-call-backend' function but "origin" is a Git-specific
>> name.  Other version control systems might name it differently.  For
>> example, in mercurial the default remote is called "default", see
>> vc-hg.el, so you'd change semantics here.
>
> Good observation, I didn't take that into account.

I have my bright moments. ;-)

>> But I get the point that "origin" is good name for "the remote which is
>> probably the central one that also hosts the bug-tracker".  Why not make
>> the patch
>>
>>> diff --git a/lisp/progmodes/bug-reference.el b/lisp/progmodes/bug-reference.el
>>> index 5c03c949049..02acac154ee 100644
>>> --- a/lisp/progmodes/bug-reference.el
>>> +++ b/lisp/progmodes/bug-reference.el
>>> @@ -393,7 +393,7 @@ bug-reference-try-setup-from-vc
>>>                                 (ignore-errors
>>>                                   (vc-call-backend backend 'repository-url
>>>                                                    file-or-dir remote)))
>>> -                             '("upstream" nil))))
>>> +                             '("upstream" "origin" nil))))
>>>      (seq-some (lambda (config)
>>>                  (apply #'bug-reference-maybe-setup-from-vc url config))
>>>                (append bug-reference-setup-from-vc-alist
>>
>> so that we ask for likely remote names first and then the default remote
>> name as defined by the VCS?
>
> That sounds reasonable to me.  Perhaps a comment above that line
> explaining the meaning of nil would be sensible.

Yes, a comment would be utmost welcome.

> I'll just wait for some feedback from Basil as well and refactor the
> patch.

I don't think you need to wait.  He basically just changed two or-ed
vc-call-backend calls to the current seq-some version, so more a
technical refactoring.

>> The downside is that in the Git case, we basically ask for "origin"
>> twice, once explicitly, once as default value for the optional
>> argument.  But a "git config ..." call is not expensive so why
>> bother.
>
> seq-some stops once a predicate returns non-nil, so I don't think that
> would be an issue.

Ah, right.  So just twice the cost in the case where there's neither
upstream nor origin.

> Regardless, the call is inexpensive indeed.

Right.

Thanks,
Tassilo