{"thread":{"id":"17918","subject":"git push usage","startedAt":"2009-02-20T09:16:26Z","lastAt":"2009-02-27T21:21:47Z","messageCount":13,"participants":["Jay Soffian","Michael J Gruber","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"105591","messageId":"76718490902200116n73e00b62sbe7bb774bcc058c5@mail.gmail.com","threadId":"17918","inReplyTo":null,"subject":"git push usage","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-20T09:16:26Z","receivedAt":"2009-02-20T09:16:26Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"The man page for git push claims:\n\n --repo=<repository>\n     This option is only relevant if no <repository> argument is passed\n     in the invocation. In this case, git-push derives the remote name\n     from the current branch: If it tracks a remote branch, then that\n     remote repository is pushed to. Otherwise, the name \"origin\" is\n     used. For this latter case, this option can be used to override the\n     name \"origin\". In other words, the difference between these two\n     commands\n\n         git push public         #1\n         git push --repo=public  #2\n\n     is that #1 always pushes to \"public\" whereas #2 pushes to \"public\"\n     only if the current branch does not track a remote branch. This is\n     useful if you write an alias or script around git-push.\n\nHowever, I'm sitting here looking at the code and I don't see how this\nis possible. I've also done some testing. So I think the man page lies\nand that forms (1) and (2) are equivalent as shown.\n\ncmd_push() is:\n\n  const char *repo = NULL; /* default repository */\n  struct option options[] = {\n    ...\n    OPT_STRING( 0 , \"repo\", &repo, \"repository\", \"repository\"),\n    ...\n  }\n\n  argc = parse_options(argc, argv, options, push_usage, 0);\n\n  if (argc > 0) {\n    repo = argv[0];\n    set_refspecs(argv + 1, argc - 1);\n  }\n\n  rc = do_push(repo, flags);\n\nSo if the user specifies --repo, then its value is assigned to *repo by\nparse_options. If the user otherwise specifies a repository w/o --repo, that\nwill be argv[0] after parse_options, so it will get assigned to *repo. Assuming\nno other arguments, set_refspecs gets called with argc = 0 and returns w/o doing\nanything.\n\nSo the only difference I can see is that form #1 allows the user to specify a\nrefspec on the command line. Form #2 does not since the first\nnon-dashed argument gets assigned to *repo, so:\n\n$ git push --repo src:dst\n\nwould assign src:dst to *repo, which would choke.\n\nSo, what's the point of the --repo dashed-option then?\n\nj.\n"},{"id":"105698","messageId":"76718490902210132w2577c093tf8c2a5e7da8bc0e8@mail.gmail.com","threadId":"17918","inReplyTo":"76718490902200116n73e00b62sbe7bb774bcc058c5@mail.gmail.com","subject":"Re: git push usage","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-21T09:32:35Z","receivedAt":"2009-02-21T09:32:35Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Tap...tap...tap... is this thing on? :-)\n\nOn Fri, Feb 20, 2009 at 4:16 AM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> The man page for git push claims:\n>\n>  --repo=<repository>\n>     This option is only relevant if no <repository> argument is passed\n>     in the invocation. In this case, git-push derives the remote name\n>     from the current branch: If it tracks a remote branch, then that\n>     remote repository is pushed to. Otherwise, the name \"origin\" is\n>     used. For this latter case, this option can be used to override the\n>     name \"origin\". In other words, the difference between these two\n>     commands\n>\n>         git push public         #1\n>         git push --repo=public  #2\n>\n>     is that #1 always pushes to \"public\" whereas #2 pushes to \"public\"\n>     only if the current branch does not track a remote branch. This is\n>     useful if you write an alias or script around git-push.\n>\n> However, I'm sitting here looking at the code and I don't see how this\n> is possible. I've also done some testing. So I think the man page lies\n> and that forms (1) and (2) are equivalent as shown.\n>\n> cmd_push() is:\n>\n>  const char *repo = NULL; /* default repository */\n>  struct option options[] = {\n>    ...\n>    OPT_STRING( 0 , \"repo\", &repo, \"repository\", \"repository\"),\n>    ...\n>  }\n>\n>  argc = parse_options(argc, argv, options, push_usage, 0);\n>\n>  if (argc > 0) {\n>    repo = argv[0];\n>    set_refspecs(argv + 1, argc - 1);\n>  }\n>\n>  rc = do_push(repo, flags);\n>\n> So if the user specifies --repo, then its value is assigned to *repo by\n> parse_options. If the user otherwise specifies a repository w/o --repo, that\n> will be argv[0] after parse_options, so it will get assigned to *repo. Assuming\n> no other arguments, set_refspecs gets called with argc = 0 and returns w/o doing\n> anything.\n>\n> So the only difference I can see is that form #1 allows the user to specify a\n> refspec on the command line. Form #2 does not since the first\n> non-dashed argument gets assigned to *repo, so:\n>\n> $ git push --repo src:dst\n>\n> would assign src:dst to *repo, which would choke.\n>\n> So, what's the point of the --repo dashed-option then?\n>\n> j.\n>\n"},{"id":"106087","messageId":"1235497240-20677-1-git-send-email-git@drmicha.warpmail.net","threadId":"17918","inReplyTo":"76718490902210132w2577c093tf8c2a5e7da8bc0e8@mail.gmail.com","subject":"[RFC] add test cases for the --repo option to git push","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-24T17:40:40Z","receivedAt":"2009-02-24T17:40:40Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"The --repo=myorigin option is supposed to change the default fallback\nremote from \"origin\" to \"myorigin\", but not override any direct argument\nnor config info of tracking branches. Add tests for this. (currently 2\nknown breakages)\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nTap tap tap....\n\nThis is an R for Comments on the desired behaviour of git push with\nrespect to --repo. I think the tests below expose that the current\nbehaviour does not match the current doc. I'm messing around in the code\nbut can't quite produce a match with the doc yet. Before investing more\ntime I'm wondering whether the code should adjusted to the doc or vice\nversa...\n\nThe code change I'm experimenting with right now is making\ndefault_remote_name a global and passing it from push. Does not look\nnice (esp. w.r.t. libification) but seems to ibe the minimally invasive\nsolution.\n\n t/t5516-fetch-push.sh |   35 +++++++++++++++++++++++++++++++++++\n 1 files changed, 35 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 89649e7..8393366 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -419,6 +419,41 @@ test_expect_success 'push with config remote.*.push = HEAD' '\n git config --remove-section remote.there\n git config --remove-section branch.master\n \n+test_expect_success 'push with --repo=repourl from non-tracking branch' '\n+\n+\tmk_test heads/master &&\n+\tgit push --repo=testrepo &&\n+\tcheck_push_result $the_commit heads/master\n+'\n+\n+# set up fake remote config\n+test_expect_success 'push with --repo=remoterepo from non-tracking branch' '\n+\n+\tmk_test heads/master &&\n+\tgit config remote.testremote.url testrepo &&\n+\tgit push --repo=testremote &&\n+\tcheck_push_result $the_commit heads/master\n+'\n+\n+# set up fake tracking info; testrepo exists, origin does not.\n+test_expect_failure 'push with --repo=repo from tracking branch with bad config' '\n+\n+\tmk_test heads/master &&\n+\tgit config branch.master.remote origin &&\n+\ttest_must_fail git push --repo=testrepo\n+'\n+\n+test_expect_failure 'push with --repo=repo from tracking branch with good config' '\n+\n+\tmk_test heads/master &&\n+\tgit config branch.master.remote testrepo &&\n+\tgit push --repo=origin &&\n+\tcheck_push_result $the_commit heads/master\n+'\n+\n+# clean up fake remote and tracking info\n+git config --unset-all branch.master.remote\n+\n test_expect_success 'push with dry-run' '\n \n \tmk_test heads/master &&\n-- \n1.6.2.rc1.30.gd43c\n"},{"id":"106266","messageId":"7vhc2iyy9y.fsf@gitster.siamese.dyndns.org","threadId":"17918","inReplyTo":"1235497240-20677-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T21:58:17Z","receivedAt":"2009-02-25T21:58:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> @@ -419,6 +419,41 @@ test_expect_success 'push with config remote.*.push = HEAD' '\n>  git config --remove-section remote.there\n>  git config --remove-section branch.master\n>  \n> +test_expect_success 'push with --repo=repourl from non-tracking branch' '\n> +\n> +\tmk_test heads/master &&\n> +\tgit push --repo=testrepo &&\n> +\tcheck_push_result $the_commit heads/master\n> +'\n> +\n> +# set up fake remote config\n> +test_expect_success 'push with --repo=remoterepo from non-tracking branch' '\n> +\n> +\tmk_test heads/master &&\n> +\tgit config remote.testremote.url testrepo &&\n> +\tgit push --repo=testremote &&\n> +\tcheck_push_result $the_commit heads/master\n> +'\n> +\n> +# set up fake tracking info; testrepo exists, origin does not.\n> +test_expect_failure 'push with --repo=repo from tracking branch with bad config' '\n> +\n> +\tmk_test heads/master &&\n> +\tgit config branch.master.remote origin &&\n> +\ttest_must_fail git push --repo=testrepo\n> +'\n\nAt this point, you have:\n\n\tbranch.master.remote = origin\n        remote.testremote.url = testrepo\n\nand nothing else related to push.  And you are asking a \"git push but\ninstead of origin please default to testrepo\".\n\nIn response to that request, in order to figure out what refs to push by\ndefault, remote.testremote.push instead of remote.origin.push will be\nconsulted, and we won't even have to notice nor complain the missing\nremote.origin.  remote.testremote.push is missing, so the push defaults to\nthe \"matching ref\" behaviour.\n\nI do not understand why you expect the above to fail.\n\n> +test_expect_failure 'push with --repo=repo from tracking branch with good config' '\n> +\n> +\tmk_test heads/master &&\n> +\tgit config branch.master.remote testrepo &&\n> +\tgit push --repo=origin &&\n> +\tcheck_push_result $the_commit heads/master\n> +'\n\nLikewise.\n\nI think the \"good/bad config\" labels given to your two test scripts are\nswapped and there is no bug or misfeature here.\n"},{"id":"106308","messageId":"49A66057.1050501@drmicha.warpmail.net","threadId":"17918","inReplyTo":"7vhc2iyy9y.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-26T09:26:47Z","receivedAt":"2009-02-26T09:26:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 25.02.2009 22:58:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> @@ -419,6 +419,41 @@ test_expect_success 'push with config remote.*.push = HEAD' '\n>>  git config --remove-section remote.there\n>>  git config --remove-section branch.master\n>>  \n>> +test_expect_success 'push with --repo=repourl from non-tracking branch' '\n>> +\n>> +\tmk_test heads/master &&\n>> +\tgit push --repo=testrepo &&\n>> +\tcheck_push_result $the_commit heads/master\n>> +'\n>> +\n>> +# set up fake remote config\n>> +test_expect_success 'push with --repo=remoterepo from non-tracking branch' '\n>> +\n>> +\tmk_test heads/master &&\n>> +\tgit config remote.testremote.url testrepo &&\n>> +\tgit push --repo=testremote &&\n>> +\tcheck_push_result $the_commit heads/master\n>> +'\n>> +\n>> +# set up fake tracking info; testrepo exists, origin does not.\n>> +test_expect_failure 'push with --repo=repo from tracking branch with bad config' '\n>> +\n>> +\tmk_test heads/master &&\n>> +\tgit config branch.master.remote origin &&\n>> +\ttest_must_fail git push --repo=testrepo\n>> +'\n> \n> At this point, you have:\n> \n> \tbranch.master.remote = origin\n>         remote.testremote.url = testrepo\n> \n> and nothing else related to push.  And you are asking a \"git push but\n> instead of origin please default to testrepo\".\n> \n> In response to that request, in order to figure out what refs to push by\n> default, remote.testremote.push instead of remote.origin.push will be\n> consulted, and we won't even have to notice nor complain the missing\n> remote.origin.  remote.testremote.push is missing, so the push defaults to\n> the \"matching ref\" behaviour.\n> \n> I do not understand why you expect the above to fail.\n\nFirst of all: I define good/bad as matching the documentation. Current\nbehaviour does not match the doc: \"git push--repo=repo\" is equivalent to\n\"git push repo\" with the current code. One could simply document it as\nsuch, of course. I took the other approach: Test for documented\nbehaviour and adjust the code.\n\nNow for the test above:\nI expect:\ngit push looks whether the branch tracks a remote.\nIt finds \"origin\" due to branch.master.remote=origin\nIt looks for a push refspec.\nIt finds none thus uses the default.\nIt pushes to origin with the default refspec and fails because there is\nno remote origin.\nThis is why I have test_must_fail\n\nI get with current behaviour:\ngit takes the --repo=testrepo argument instead of the tracking info.\npush succeeds accordingly.\nThis is why I have test_expect_failure.\n\nAfter the fix in PATCH 2/2, the behaviour matches exactly what I\ndescribed under expect. Note that I did not change the handling of\ntracking info etc. at all in the PATCH, I only changed the treatment of\nthe --repo option and produced the expected behaviour.\n\n>> +test_expect_failure 'push with --repo=repo from tracking branch with good config' '\n>> +\n>> +\tmk_test heads/master &&\n>> +\tgit config branch.master.remote testrepo &&\n>> +\tgit push --repo=origin &&\n>> +\tcheck_push_result $the_commit heads/master\n>> +'\n> \n> Likewise.\n\nUhm, yes, likewise ;)\nExpect:\ngit push looks whether the branch tracks a remote.\nIt finds \"testrepo\" due to branch.master.remote=testrepo\nIt looks for a push refspec.\nIt finds none thus uses the default.\nIt pushes to testrepo with the default refspec and succeeds (exists, has\nmatching refs).\nFor extra safety, I check that the push produced the correct ref on the\nremote side.\nThis is why I expect it to succeed.\n\nI get with current behaviour:\ngit takes the --repo=origin argument instead of the tracking info.\npush fails because there is no remote origin.\nThis is why I have test_expect_failure.\n\nNote that according to the doc, \"git push --repo=origin\" is equivalent\nto \"git push\", but this test shows that it is not currently.\n\nAfter PATCH 2/2 the test succeeds as expected.\n\n> I think the \"good/bad config\" labels given to your two test scripts are\n> swapped and there is no bug or misfeature here.\n\nWell, there's a discrepancy between doc and behaviour, as reported by\nJay. The proposed patch brings them in line the hard way\n(fixing/adjusting the code).\n\nMichael\n"},{"id":"106345","messageId":"7vfxi1t99u.fsf@gitster.siamese.dyndns.org","threadId":"17918","inReplyTo":"49A66057.1050501@drmicha.warpmail.net","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-26T17:09:33Z","receivedAt":"2009-02-26T17:09:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> First of all: I define good/bad as matching the documentation.\n\nOk, I was primarily working from this:\n\ncommit bcc785f611dc6084be75999a3b6bafcc950e21d6\nAuthor: Linus Torvalds <torvalds@osdl.org>\nDate:   Mon Oct 30 08:28:59 2006 -0800\n\n    git push: add verbose flag and allow overriding of default target repository\n    \n    This adds a command line flag \"-v\" to enable a more verbose mode, and\n    \"--repo=\" to override the default target repository for \"git push\" (which\n    otherwise always defaults to \"origin\").\n    \n    This, together with the patch to allow dashes in config variable names,\n    allows me to do\n    \n    \t[alias]\n    \t\tpush-all = push -v --repo=all\n    \n    in my user-global config file, and then I can (for any project I maintain)\n    add to the project-local config file\n    \n    \t[remote \"all\"]\n    \t\turl=one.target.repo:/directory\n    \t\turl=another.target:/pub/somewhere/else\n    \n    and now \"git push-all\" just updates all the target repositories, and shows\n    me what it does - regardless of which repo I am in.\n    \n    Signed-off-by: Linus Torvalds <torvalds@osdl.org>\n    Signed-off-by: Junio C Hamano <junkio@cox.net>\n\nIf documentation does not match it, we need to figure out why J6t with\nbf07cc5 (git-push.txt: Describe --repo option in more detail, 2008-10-07)\nneeded to update the documentation.\n\nIt could be that the behaviour changed (perhaps by accident, perhaps by\ndesign) after Linus introduced --repo with bcc785f (git push: add verbose\nflag and allow overriding of default target repository, 2006-10-30) and\nJ6t documented that updated behaviour.  And since then there was another\nbehaviour change (again, perhaps by accident, perhaps by design) that made\nyou notice the description does not match the behaviour.\n\nYou will see that:\n\n (1) bf07cc5 (i.e. J6t's documentation) passes your tests;\n\n (2) somewhere between that and v1.6.2-rc2, there is a regression to make\n     your test fail.\n\nif the above conjecture is true, and we may want to fix that regression to\nmatch the documentation.\n\nOn the other hand, if bf07cc5 does not pass your tests, it means that the\ndocumentation update was the cause of the confusion, and it is not the\nbehaviour that needs to be fixed.\n\nSorry, but I do not have time today to look into this.  Could you help?\n"},{"id":"106346","messageId":"49A6D5E5.8000007@drmicha.warpmail.net","threadId":"17918","inReplyTo":"7vfxi1t99u.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-26T17:48:21Z","receivedAt":"2009-02-26T17:48:21Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 26.02.2009 18:09:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> First of all: I define good/bad as matching the documentation.\n> \n> Ok, I was primarily working from this:\n> \n> commit bcc785f611dc6084be75999a3b6bafcc950e21d6\n> Author: Linus Torvalds <torvalds@osdl.org>\n> Date:   Mon Oct 30 08:28:59 2006 -0800\n> \n>     git push: add verbose flag and allow overriding of default target repository\n>     \n>     This adds a command line flag \"-v\" to enable a more verbose mode, and\n>     \"--repo=\" to override the default target repository for \"git push\" (which\n>     otherwise always defaults to \"origin\").\n>     \n>     This, together with the patch to allow dashes in config variable names,\n>     allows me to do\n>     \n>     \t[alias]\n>     \t\tpush-all = push -v --repo=all\n>     \n>     in my user-global config file, and then I can (for any project I maintain)\n>     add to the project-local config file\n>     \n>     \t[remote \"all\"]\n>     \t\turl=one.target.repo:/directory\n>     \t\turl=another.target:/pub/somewhere/else\n>     \n>     and now \"git push-all\" just updates all the target repositories, and shows\n>     me what it does - regardless of which repo I am in.\n>     \n>     Signed-off-by: Linus Torvalds <torvalds@osdl.org>\n>     Signed-off-by: Junio C Hamano <junkio@cox.net>\n> \n> If documentation does not match it, we need to figure out why J6t with\n> bf07cc5 (git-push.txt: Describe --repo option in more detail, 2008-10-07)\n> needed to update the documentation.\n> \n> It could be that the behaviour changed (perhaps by accident, perhaps by\n> design) after Linus introduced --repo with bcc785f (git push: add verbose\n> flag and allow overriding of default target repository, 2006-10-30) and\n> J6t documented that updated behaviour.  And since then there was another\n> behaviour change (again, perhaps by accident, perhaps by design) that made\n> you notice the description does not match the behaviour.\n> \n> You will see that:\n> \n>  (1) bf07cc5 (i.e. J6t's documentation) passes your tests;\n> \n>  (2) somewhere between that and v1.6.2-rc2, there is a regression to make\n>      your test fail.\n\nI see. Back then I checked whether there was a change to git-push at or\nafter J6t's doc commit, and there was none, but I didn't test. I'll do now.\n\n> if the above conjecture is true, and we may want to fix that regression to\n> match the documentation.\n> \n> On the other hand, if bf07cc5 does not pass your tests, it means that the\n> documentation update was the cause of the confusion, and it is not the\n> behaviour that needs to be fixed.\n\n>From Linus' description it's not clear to me what should happen when\nthere is no explicit repo argument but the branch is tracking a remote\nand there is a --repo option. And I think this case is the only open\nquestion: Should the option win or the tracking config? Code does\noption, doc says tracking config.\n\n[Also, I don't see immediately what's wrong with \"alias.push-all = push\n-v all\", in the current situation where option and arg are equivalent,\nbut I haven't tried.]\n\nI'm cc'ing Linus to make sure J6t's (current) doc describes the original\nintent for --repo and my patch isn't stepping on /some/one's toes...\n\n> Sorry, but I do not have time today to look into this.  Could you help?\n\nOf course. I ursurpated someone else's itch here, but now it's mine ;)\n\nI'll bisect. Seems to be the right thing to do while watching soccer\nlater in the evening...\n\nMichael\n"},{"id":"106366","messageId":"76718490902261411pc8b97wdb43baf02eebe0c3@mail.gmail.com","threadId":"17918","inReplyTo":"49A6D5E5.8000007@drmicha.warpmail.net","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-26T22:11:37Z","receivedAt":"2009-02-26T22:11:37Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Feb 26, 2009 at 12:48 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n\n> Of course. I ursurpated someone else's itch here, but now it's mine ;)\n\nWell then, I owe you one. In the mean time, thank you. :-)\n\nj.\n"},{"id":"106422","messageId":"49A7C3A7.6060202@drmicha.warpmail.net","threadId":"17918","inReplyTo":"7vfxi1t99u.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-27T10:42:47Z","receivedAt":"2009-02-27T10:42:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 26.02.2009 18:09:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> First of all: I define good/bad as matching the documentation.\n> \n> Ok, I was primarily working from this:\n> \n> commit bcc785f611dc6084be75999a3b6bafcc950e21d6\n> Author: Linus Torvalds <torvalds@osdl.org>\n> Date:   Mon Oct 30 08:28:59 2006 -0800\n\n\n[snip]\n> You will see that:\n> \n>  (1) bf07cc5 (i.e. J6t's documentation) passes your tests;\n\nHmm, I don't see that, we must be doing something differently, see below.\n\n>  (2) somewhere between that and v1.6.2-rc2, there is a regression to make\n>      your test fail.\n> \n> if the above conjecture is true, and we may want to fix that regression to\n> match the documentation.\n> \n> On the other hand, if bf07cc5 does not pass your tests, it means that the\n> documentation update was the cause of the confusion, and it is not the\n> behaviour that needs to be fixed.\n> \n> Sorry, but I do not have time today to look into this.  Could you help?\n\nI'll try and provide the necessary info below, but I think there is a\ndecision to be made about the desired order of priorities for \"repo\nargument\", \"repo option (--repo=)\" and \"tracking info config\n(branch.$branch.remote=)\".\n\nCurrent code: argument > option > track config > 'origin'\nCurrent doc: argument > track config > option > 'origin'\n\nI'd say the documented version is more natural, meaning --repo=$repo is\nfully equivalent to changing \"origin\" to \"$repo\".\n\nNow, here's if you want to know the details:\n\nWhen Linus introduced \"--repo\" there was no heeding of the tracking info\nat all:\n\nbcc785f (git push: add verbose flag and allow overriding of default\ntarget repository, 2006-10-30) Linus introduces --repo.\n\n5751f49 (Move remote parsing into a library file out of builtin-push.,\n2007-05-12) Daniel Barkalow introduces the use of branch.$branch.remote\ninfo for the repo if git push has no other repo arguments nor --repo\noptions.\n\n378c483 (Use parseopts in builtin-push, 2007-11-04) Daniel switches\ngit-push to parseopts, without changing the behaviour.\n\nbf07cc5 (git-push.txt: Describe --repo option in more detail,\n2008-10-07) J6t writes the current version of the doc.\n\nUsing a trimmed down ./t5516-fetch-push.sh from my patch (and a copy of\ncurrent test-lib), all 4 of them give the same results:\n\n*   ok 1: setup\n*   ok 2: push with --repo=repourl from non-tracking branch\n*   ok 3: push with --repo=remoterepo from non-tracking branch\n* FAIL 4: push with --repo=repo from tracking branch with bad config\n\n\n                mk_test heads/master &&\n                git config branch.master.remote origin &&\n                test_must_fail git push --repo=testrepo\n\n* FAIL 5: push with --repo=repo from tracking branch with good config\n\n\n                mk_test heads/master &&\n                git config branch.master.remote testrepo &&\n                git push --repo=origin &&\n                check_push_result $the_commit heads/master\n\n[testrepo exists, origin does not]\n\nNote that bcc785f was not even supposed to heed the value of\nbranch.master.remote, so it's clear they fail 4&5. 2&3 only test whether\n--repo is considered if there's no other info, so it's clear they pass\n(versions without bcc785f would fail).\n\nCheers,\nMichael\n"},{"id":"106449","messageId":"7vy6vrkcmo.fsf@gitster.siamese.dyndns.org","threadId":"17918","inReplyTo":"49A7C3A7.6060202@drmicha.warpmail.net","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-27T17:34:07Z","receivedAt":"2009-02-27T17:34:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Junio C Hamano venit, vidit, dixit 26.02.2009 18:09:\n>> Michael J Gruber <git@drmicha.warpmail.net> writes:\n>> \n>>> First of all: I define good/bad as matching the documentation.\n>> \n>> Ok, I was primarily working from this:\n>> \n>> commit bcc785f611dc6084be75999a3b6bafcc950e21d6\n>> Author: Linus Torvalds <torvalds@osdl.org>\n>> Date:   Mon Oct 30 08:28:59 2006 -0800\n>\n>\n> [snip]\n>> You will see that:\n>> \n>>  (1) bf07cc5 (i.e. J6t's documentation) passes your tests;\n>\n> Hmm, I don't see that, we must be doing something differently, see below.\n\nNo, I didn't even know if the commit passed your tests.  Before the [snip]\nI think I had something like:\n\n\tIf your claim that this is a bug is true, it might have happened\n\tthis way: Linus originally wrote it, behaviour changed, J6t\n\tdocumented the updated behaviour, behaviour changed again.\n\nand after (1)/(2)/..., I have:\n\n>> if the above conjecture is true, and we may want to fix that regression to\n>> match the documentation.\n\nSo if you don't see that, it merely proves that the conjecture is false.\nThe updated documentation didn't describe correctly what should happen and\nthere is no bug other than in the documentation.\n\nIt's a different matter if we want to update the semantics, but I am not\nsure if people agree with \"the documented version is more natural\".  I'm\nneutral right now.  I may have more to say after I re-read the detailed\nanalysis part of your message.\n"},{"id":"106474","messageId":"76718490902271248p2de44082ka66645203c9683d4@mail.gmail.com","threadId":"17918","inReplyTo":"49A7C3A7.6060202@drmicha.warpmail.net","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-27T20:48:18Z","receivedAt":"2009-02-27T20:48:18Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Feb 27, 2009 at 5:42 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> bcc785f (git push: add verbose flag and allow overriding of default\n> target repository, 2006-10-30) Linus introduces --repo.\n\nSo I still don't get why Linus introduced the option. I'm looking at\nbcc785f:builtin-push.c and AFAICT, the following are exactly\nequivalent:\n\n$ git push [options]... <repo>\n$ git push [options]... --repo=<repo>\n\nWhich is why I sent the original message that has spawned this saga. :-)\n\nHere's the abbreviated code in question:\n\n        const char *repo = \"origin\";    /* default repository */\n\n        for (i = 1; i < argc; i++) {\n                const char *arg = argv[i];\n                if (arg[0] != '-') {\n                        repo = arg;\n                        i++;\n                        break;\n                }\n                if (!strncmp(arg, \"--repo=\", 7)) {\n                        repo = arg+7;\n                        continue;\n                }\n        }\n        set_refspecs(argv + i, argc - i);\n        return do_push(repo);\n\n--repo can be placed anywhere on the command line, but other than\nthat, it's identical in effect to specifying the repo as the first\nnon-dashed argument.\n\nOr am I completely blind?\n\nj.\n"},{"id":"106478","messageId":"alpine.LFD.2.00.0902271255530.3111@localhost.localdomain","threadId":"17918","inReplyTo":"76718490902271248p2de44082ka66645203c9683d4@mail.gmail.com","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-02-27T21:00:21Z","receivedAt":"2009-02-27T21:00:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 27 Feb 2009, Jay Soffian wrote:\n> \n> So I still don't get why Linus introduced the option. I'm looking at\n> bcc785f:builtin-push.c and AFAICT, the following are exactly\n> equivalent:\n> \n> $ git push [options]... <repo>\n> $ git push [options]... --repo=<repo>\n\nYes. \n\nBut now do\n\n\t[alias]\n\t\tpush-all=push all\n\nand then try to add those options AFTERWARDS!\n\n> --repo can be placed anywhere on the command line, but other than\n> that, it's identical in effect to specifying the repo as the first\n> non-dashed argument.\n> \n> Or am I completely blind?\n\nIt's the \"placed anywhere on the command line\" that is the important part.\n\nTry \n\n\tgit push-all --tags\n\nand it didn't use to work without \"--repo=all\".\n\nOf course, I think it works now, because I think \"git push\" uses \n\"parse_options\" these days, so now \"--tags\" actually works even after the \nrepository definition. So _these_ days, you can just do\n\n\tgit push all --tags\n\nbut that was not true historically. Back then, if you wanted to use an \nalias (which mean that the repo was named _before_ the arguments), you \nneeded to do\n\n\tgit push --repo=all --tags\n\nbecause putting \"--tags\" after the repository name wouldn't work.\n\nSo _today_, we could remove the use of \"--repo\". But today, we have \nanother reason to do \"--repo\" - compatibility.\n\n\t\tLinus\n"},{"id":"106482","messageId":"76718490902271321i7f6c2b01g8ded98b7ab39f549@mail.gmail.com","threadId":"17918","inReplyTo":"alpine.LFD.2.00.0902271255530.3111@localhost.localdomain","subject":"Re: [RFC] add test cases for the --repo option to git push","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-27T21:21:47Z","receivedAt":"2009-02-27T21:21:47Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Feb 27, 2009 at 4:00 PM, Linus Torvalds\n<torvalds@linux-foundation.org> wrote:\n> So _today_, we could remove the use of \"--repo\". But today, we have\n> another reason to do \"--repo\" - compatibility.\n\nI was not suggesting removing --repo. I just didn't understand why it existed.\n\nThanks for the clarification.\n\nj.\n"}]}