Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> But here you do not have a pushurl defined in the first place. So I >> guess this is really just a shortcut for swapping the two, like: >> >> git remote set-url --push gh $(git config remote.gh.url) >> git remote set-url gh new-fetch-url > > It seems that this swapping is only necessary because the repository > is set up in this way: > > $ browser github.com > ... fork upstream to your own publishing repository ... > $ git clone <your publish repo> > ... oops, I am set up to fetch from myself ... > $ git remote set-url --push mine <url for your publish repo> > $ git remote set-url <url for your upstream repo> > > If you are fetching from somebody else and then pushing into your > own publishing repository (i.e. fork of that upstream), why isn't > the sequence of event like this, instead? > > $ git clone $upstream > $ browser github.com > ... fork upstream to your own publishing repository ... > $ git remote set-url --push mine <url for your publish repo> > > Isn't this one of those bad workflows encouraged by GitHub, for > which you guys have to be punished ;-)? I re-read the original and Peter is really accessing the same repository, only over different transports. Cloning via ssh:// but later deciding to push via ssh:// but to fetch via https:// (or vice versa; the important point is that clone was done over a transport that is "wrong" for future fetching). Of course, if you cloned via a wrong transport that is not suitable for whatever reason for later fetching, you would need to have a way to "swap", so the observation I made in the message I am following up on does not apply to this thread at all. Please scratch all of the above. Coming back to the topic, how common would this "oops, I cloned via a wrong transport" be? I am not opposed to giving a recovery method for gotcha that does not happen very often, but if such an addition adds undue confusion factor for people who use "set-url" for more common cases, that would be a bad trade-off. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html