Re: [RFC] [PATCH] remote: add new --fetch option for set-url

[Peter Wu <peter@lekensteyn.nl>]

On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > Jeff King <peff@peff.net> writes:
> > 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 ;-)?

For "forks", it usually goes like this:

    git clone $upstream
    ... realizes that is has a bug which I want to fix ...
    ... creates a new repo ...
    git remote rename origin upstream
    git remote add origin git@$personal_repo
    # "--fetch" is what I need
    git remote add --fetch https://$personal_repo

I often start by entering/copying the ssh URL which is what I need for
pushing. Later ssh-agent forget about my key and I realize that push
works fine over https, so would like to set that... only to observe that
is not possible in an straightforward way through 'git remote'.

> 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.

Well, people rarely need to use 'git remote' except when, well, they
need to modify the remotes. Where does the confusion come from? I might
be biased now that I know the internals. Maybe the https/ssh case above
needs to be mentioned in the documentation? What do you think of the
updated documentation by the way?
-- 
Kind regards,
Peter
https://lekensteyn.nl