Re: [BUG] Possible bug in `remote set-url --add --push`
On 14/01/2013, at 17:09, Junio C Hamano gits...@pobox.com wrote: Michael J Gruber g...@drmicha.warpmail.net writes: It seems to me that everything works as designed, and that the man page talk about push URLs can be read in two ways,... Hmph, but I had an impression that Jardel's original report was that one of the --add --pushurl was not adding but was replacing. If that was a false alarm, everything you said makes sense to me. Thanks. I failed to explain my reasoning. But I learned quite a bit from this discussion. I understood that the defaul push url is not used by git-push when there's at least one pushurl for a given remote. If that's by design, I still fail to comprehend the exact reason. If you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience. Imagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push 2nd-repo` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo. This is exactly what I thought to be a bug. If it's intended to work the way I described in the previous scenario, I'll have to ask and/or research to understand the reason behind this -- Why does having a pushurl make git-push _not_ to push to the default push location (the 1st repo in my scenario) as well? Could you describe a scenario in which that behavior is useful and/or better than the behavior I expected? Please, pardon me for not being as clear as needed. I appreciate your time on this. Thank you all. Sent from my mobile.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Possible bug in `remote set-url --add --push`
Step 1:
jweyrich@pharao:test_clone1 [* master]$ git remote -v
origin /Volumes/sandbox/test (fetch)
origin /Volumes/sandbox/test (push)
jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\.origin'
remote.origin.url=/Volumes/sandbox/test
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
Step 3:
jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add
--push origin /Volumes/sandbox/test_clone2
origin /Volumes/sandbox/test (fetch)
origin /Volumes/sandbox/test_clone2/ (push)
jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\.origin'
remote.origin.url=/Volumes/sandbox/test
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.pushurl=/Volumes/sandbox/test_clone2/
After that, if I do a commit in test_clone1 and try to push to origin,
it pushes only to the test_clone2 rather than pushing to both test and
test_clone2 (it's a bare repo, sorry for using a misleading name).
Is `remote.remote_name.pushurl` required for the primary URL as
well? If not, then git-push is not handling that information as it
should.
On Sat, Jan 12, 2013 at 5:10 AM, Junio C Hamano gits...@pobox.com wrote:
Jardel Weyrich jweyr...@gmail.com 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.
-- 8 --
From 0f6cbc67db926e97707ae732b02e790b4604508e Mon Sep 17 00:00:00 2001
From: Junio C Hamano gits...@pobox.com
Date: Fri, 11 Jan 2013 23:04:16 -0800
Subject: [PATCH] t5505: adding one pushurl from jweyrich
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5505-remote.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c03ffdd..b31c5bb 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -901,6 +901,25 @@ test_expect_success 'remote set-url --push --add aaa' '
cmp expect actual
'
+test_expect_success 'remote set-url --push --add' '
+ git config remote.jweyrich.url /Volumes/sandbox/test
+ git config remote.jweyrich.pushurl /Volumes/sandbox/test
+ git config remote.jweyrich.fetch
refs/heads/*:refs/remotes/jweyrich/*
+
+ added=/Volumes/sandbox/test_clone2
+ {
+ git config -l | grep ^remote\.jweyrich\.
+ echo remote.jweyrich.pushurl=$added
+ } | sort expect
+
+ git remote set-url --add --push jweyrich $added
+ git config -l | grep ^remote\.jweyrich\. | sort actual
+
+ test_cmp expect actual
+
+ git remote -v | grep ^jweyrich # this is just for debugging
+'
+
test_expect_success 'remote set-url --push bar aaa' '
git remote set-url --push someremote bar aaa
echo foo expect
--
1.8.1.421.g6236851
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Possible bug in `remote set-url --add --push`
On Sat, Jan 12, 2013 at 6:44 AM, Sascha Cunz sascha...@babbelbox.org wrote: Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano: Jardel Weyrich jweyr...@gmail.com 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 url. (From the section REMOTES - Named remote in configuration file) the command: git remote add foo g...@foo-fetch.org/some.git will set remote.foo.url to g...@foo-fetch.org. Subsequently, fetch and push will use g...@foo-fetch.org as url. Fetch will use this url, because remote.foo.url explicitly sets this. push will use it in absence of a remote.foo.pushurl. Now, we're adding a push-url: git remote set-url --add --push foo g...@foo-push.org/some.git Relevant parts of config are now looking like: [remote foo] url = g...@foo-fetch.org/some.git pushurl = g...@foo-push.org/some.git 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 g...@foo-push-also.org/some.git the next git-push will push to foo-push.org and foo-push-also.org. Now, using --set-url --delete on both of these urls restores the original state: only remote.foo.url 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? You're right. However, as I quoted earlier, the git-remote man-page states: set-url Changes URL remote points to. suppressed With --push, push URLs are manipulated instead of fetch URLs. With --add, instead of changing some URL, new URL is added. It explicitly mentions that it should **add a new URL**. So when I do `git remote set-url --add --push origin git://another/repo.git`, I expect git-push to use both the default push URL and the new one. Or am I misinterpreting the man-page? Might be that the bug actually is that the expectation was git remote add foo g...@foo-fetch.org/some.git should have created a config like: [remote foo] url = g...@foo-fetch.org/some.git pushurl = g...@foo-fetch.org/some.git 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 url. Correct. Adding a remote doesn't automatically generate a pushurl for it. To me, it seems that git-push checks for the existence of pushurl's in the config, and if it finds any, it ignores the defaul push URL during the actual push. In better words, it pushes only to pushurls, if it finds any, otherwise it pushes to the default URL. To comply with the statements in the git-remote man-page, git-remote should add
[BUG] Possible bug in `remote set-url --add --push`
Hi, 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) 4. Missing an URL? Re-add the original one jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \ /Volumes/sandbox/test 5. Check what happened, again jweyrich@pharao:test_clone1 [* master]$ git remote -v origin /Volumes/sandbox/test (fetch) origin /Volumes/sandbox/test_clone2 (push) origin /Volumes/sandbox/test (push) 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. Please, could someone try to reproduce? - jw -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
