Patrick Steinhardt <ps@xxxxxx> writes: > 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.
