Re: [lmi] Relocating a proprietary git repository

[Vadim Zeitlin]

On Fri, 4 Mar 2022 20:18:13 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> Referring back to the 'set-url' documentation, I find
GC> a later paragraph that says:
GC> 
GC> | Note that the push URL and the fetch URL, even though they
GC> | can be set differently, must still refer to the same place.

 I think the documentation is not very clear here. To the best of my
knowledge, there is no hard requirement for these URLs to refer to the same
place, even though they should, of course, refer to "the same" (in some
meaning of this word) repository.

 E.g. the same paragraph continues to say

        What you pushed to the push URL should be what you would see if you
        immediately fetched from the fetch URL.

but I'm quite sure that you could relax this by omitting "immediately", for
example, in order to allow updating the "fetch" URL destination from "push"
URL with a delay, as it happens when you mirror a Git repository somewhere
else.

GC> This seems to be an invariant that's expressed only in
GC> the fifth of five paragraphs in the documentation, but
GC> violating it elicited no error or warning.

 It's not really possible to reliably check if 2 URLs refer to the same
repository, even in the narrow sense (one URL could use HTTP(S) and another
ssh, for example, potentially with different user names).

GC> And it was indeed violated

 But I don't think this is really a problem, as long as you know what
you're doing (which, of course, applies to quite a few other Git commands
too).

 In any case, I agree that playing these games with push/fetch/multiple
URLs for the same remote is useful only in very specific situations and
that in the vast majority of cases there should be just one URL used for
both operations -- and multiple remotes should be used for different
repositories.

 Regards,
VZ

pgpm1Z57s9vjN.pgp
Description: PGP signature