Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:
> Jardel Weyrich <> writes:
> > I believe `remote set-url --add --push` has a bug. Performed tests
> > with v1.8.0.1 and v1.8.1 (Mac OS X).
> > 
> > Quoting the relevant part of the documentation:
> >> set-url
> >> 
> >>     Changes URL remote points to. Sets first URL remote points to
> >>     matching regex <oldurl> (first URL if no <oldurl> is given) to
> >>     <newurl>. If <oldurl> doesn’t match any URL, error occurs and
> >>     nothing is changed.
> >>     
> >>     With --push, push URLs are manipulated instead of fetch URLs.
> >>     With --add, instead of changing some URL, new URL is added.
> >>     With --delete, instead of changing some URL, all URLs matching regex
> >>     <url> are deleted. Trying to delete all non-push URLs is an error.> 
> > Here are some steps to reproduce:
> > 
> > 1. Show the remote URLs
> > 
> > jweyrich@pharao:test_clone1 [* master]$ git remote -v
> > origin  /Volumes/sandbox/test (fetch)
> > origin  /Volumes/sandbox/test (push)
> > 
> > 2. Add a new push URL for origin
> > 
> > jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push
> > origin \> 
> >     /Volumes/sandbox/test_clone2
> > 
> > 3. Check what happened
> > 
> > jweyrich@pharao:test_clone1 [* master]$ git remote -v
> > origin  /Volumes/sandbox/test (fetch)
> > origin  /Volumes/sandbox/test_clone2 (push)
> The original pushurl was replaced with the additional one, instead
> of being left and the new one getting added.  That looks certainly
> wrong.
> However, the result of applying the attached patch (either to
> v1.7.12 or v1.8.1) still passes the test and I do not think it is
> doing anything differently from what you described above.
> What do you get from
>       git config -l | grep '^remote\.origin'
> in steps 1. and 3. in your procedure?  This question is trying to
> tell if your bug is in "git remote -v" or in "git remote set-url".

I'm not sure, if there is a bug at all. According to man git-push:

        The <pushurl> is used for pushes only. It is optional and defaults to
        (From the section REMOTES -> Named remote in configuration file)

the command:
    git remote add foo

will set "" to "". Subsequently, fetch and push 
will use as url.
Fetch will use this url, because "" explicitly sets this. push 
will use it in absence of a "".

Now, we're adding a push-url:
    git remote set-url --add --push foo

Relevant parts of config are now looking like:
        [remote "foo"]
        url =
        pushurl =

Since, pushurl is now given explicitly, git push will use that one (and only 
that one).

If we add another push-url now,
    git remote set-url --add --push foo

the next git-push will push to and

Now, using --set-url --delete on both of these urls restores the original 
state: only "" is set; meaning implicitly pushurl defaults to 
url again.

To me this is exactly what Jardel was observing:

> In step 2, Git replaced the original push URL instead of adding a new
> one. But it seems to happen only the first time I use `remote set-url
> --add --push`. Re-adding the original URL using the same command seems
> to work properly.

> And FWIW, if I delete (with "set-url --delete") both URLs push, Git
> restores the original URL.

Or am I missing something here?

Might be that the "bug" actually is that the expectation was

        git remote add foo

should have created a config like:

        [remote "foo"]
        url =
        pushurl =

since that is what "git remote -v" reports.

If that is the case, we might want to amend the output of 'git remote -v' with 
the information that a pushurl is not explicitly given and thus defaults to 

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to