ping?
I asked around and the people who know of `git remote` fell in these two
categories:
- those who know of this "bug" and then first set the fetch URL and
then the push URL.
- those who did not expect the current behavior.
The command 'git remote set-url NAME URL' reads as "set the URL(s) for
remote NAME to URL". Currently it means "set the fetch (and push) URL of
remote NAME to URL" (depending on whether pushurl is set).
I propose to add the option --fetch next to --push with the meaning "set
the fetch/push URL of remote NAME to URL". Then --fetch --push means
"set the fetch and push URL of remote NAME to URL". In a future git
version, this could be made the default option to avoid surprises (which
would be backwards incompatible though).
As for the changelog entry,
The "git remote set-url" command now allows you to change just the
fetch URL without modifying the push URL using the new --fetch
option. For symmetry with the --push option.
("symmetry" in the eyes of the user, not how it is implemented in the
git config.)
Opinions?
On Wednesday 19 November 2014 22:28:35 Peter Wu wrote:
> On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
> > Junio C Hamano <gitster@xxxxxxxxx> writes:
> > > Jeff King <peff@xxxxxxxx> 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?
--
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