Re: [PATCH v2 3/4] Add 'promisor-remote' capability to protocol v2

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 1, 2024, 18:47 UTC
Message-ID: <xmqqr08zwth2.fsf@gitster.g>
In-Reply-To: <ZvvLbXskyA4V0gM3@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 5 quoted lines

> Now I'm not against advertising a name and storing it in our config when
> we create the additional remote, for example by storing it as a separate
> key "remote.<generated>.promisor-name". But the name of the remote
> itself should not be controlled by the server, but should instead be
> generated by the client.

Thanks. In an earlier round of the review, I noticed that the remote side gives each promisor remote it suggests a name, but I failed to realize that it is used without any say from the user at the receiving end in the local repository---which is horrible.

The remote end wants to keep referring to a promisor remote in such a way that both sides can understand when the same promisor remote is referred to in the future, and I am OK for the protocol to allow the remote to give a name to a promisor remote. Such a name needs to be kept separate from the name the end-user locally uses to refer to the promisor remote (if they follow the suggestion given over the protocol). Do we need some mapping mechanism to do so? A name N the remote A gave to another remote B has to keep referring to the remote we know as B today, even if we rename B to C.

Thanks.