{"thread":{"id":"42248","subject":"wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","startedAt":"2016-05-06T13:18:55Z","lastAt":"2016-05-11T21:27:32Z","messageCount":8,"participants":["Yaroslav Halchenko","Junio C Hamano","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"285699","messageId":"20160506131855.GD7907@onerussian.com","threadId":"42248","inReplyTo":null,"subject":"wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-05-06T13:18:55Z","receivedAt":"2016-05-06T13:18:55Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"Dear Git Folks,\n\nOriginally this issue was mentioned in previous thread [1], and I have decided\nto bring it into a separate thread. ATM there is a dichotomy in git behavior\nbetween cloning non-bare repos: if I clone over ssh or just locally by\nproviding url without trailing /.git, git senses for /.git and works just fine\nwith ssh or local repositories, but fails for \"dummy\" http ones, the demo\nscript is here [2] which produces output listed below. From which you can see\nthat cloning using http URL to the repository without /.git fails (git version\n2.8.1, Debian). As it was noted in [1], concern could have been to not\ntraverse website since could lead to dangerous places. But .git is under\noriginating url directory, as well as info/ or HEAD or any other object\naccessed by git, so IMHO this concern is not a concern.\n\nSo do you think that cloning from http urls could be adjusted so git senses\nfor presence of .git/ subdirectory if originating url is missing necessary\n/info/refs?.... ? That would make behavior uniform and help us and users in\nmany use-cases IMHO (in particular with relative paths to submodules as in\n[1])\n\nThank you in advance, and please maintain CC\n\n$> /tmp/democlone\nInitiating repo\ncloning via ssh: localhost:/tmp/repo1\nCloning into 'repo1-ssh'...\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nReceiving objects: 100% (3/3), done.\nChecking connectivity... done.\nSUCCESS\ncloning locally: /tmp/repo1\nCloning into 'repo1-local'...\ndone.\nSUCCESS\nstarting local http server\nServing HTTP on 0.0.0.0 port 8080 ...\ncloning via http: http://localhost:8080/repo1\nCloning into 'repo1-http-failed'...\n127.0.0.1 - - [06/May/2016 09:13:41] code 404, message File not found\n127.0.0.1 - - [06/May/2016 09:13:41] \"GET /repo1/info/refs?service=git-upload-pack HTTP/1.1\" 404 -\nfatal: repository 'http://localhost:8080/repo1/' not found\nFAILED\ndoing with /.git: http://localhost:8080/repo1/.git\nCloning into 'repo1-http'...\n127.0.0.1 - - [06/May/2016 09:13:41] \"GET /repo1/.git/info/refs?service=git-upload-pack HTTP/1.1\" 200 -\n127.0.0.1 - - [06/May/2016 09:13:41] \"GET /repo1/.git/HEAD HTTP/1.1\" 200 -\n127.0.0.1 - - [06/May/2016 09:13:41] \"GET /repo1/.git/objects/36/31fa81eb6422349035c915a5a11b177688f491 HTTP/1.1\" 200 -\n127.0.0.1 - - [06/May/2016 09:13:41] \"GET /repo1/.git/objects/12/ddeb87cc045cd67063e95125fbeb014bd1d9b1 HTTP/1.1\" 200 -\n127.0.0.1 - - [06/May/2016 09:13:41] \"GET /repo1/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 HTTP/1.1\" 200 -\nChecking connectivity... done.\nSUCCESS\n\n\n\n[1] problems serving non-bare repos with submodules over http\nhttp://thread.gmane.org/gmane.comp.version-control.git/292032\n[2] http://www.onerussian.com/tmp/democlone\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834 Fax: +1 (603) 646-1419\nWWW: http://www.linkedin.com/in/yarik \n"},{"id":"286095","messageId":"20160510190652.GI7907@onerussian.com","threadId":"42248","inReplyTo":"20160506131855.GD7907@onerussian.com","subject":"Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-05-10T19:06:52Z","receivedAt":"2016-05-10T19:06:52Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Fri, 06 May 2016, Yaroslav Halchenko wrote:\n\n> Dear Git Folks,\n\n> Originally this issue was mentioned in previous thread [1], and I have decided\n> to bring it into a separate thread. ATM there is a dichotomy in git behavior\n> between cloning non-bare repos: if I clone over ssh or just locally by\n> providing url without trailing /.git, git senses for /.git and works just fine\n> with ssh or local repositories, but fails for \"dummy\" http ones, the demo\n> script is here [2] which produces output listed below. From which you can see\n> that cloning using http URL to the repository without /.git fails (git version\n> 2.8.1, Debian). As it was noted in [1], concern could have been to not\n> traverse website since could lead to dangerous places. But .git is under\n> originating url directory, as well as info/ or HEAD or any other object\n> accessed by git, so IMHO this concern is not a concern.\n> ...\n\nIf there is a better venue (bug tracker?) to spark the interest\nand discussion, please let me know ;)\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834 Fax: +1 (603) 646-1419\nWWW: http://www.linkedin.com/in/yarik \n"},{"id":"286105","messageId":"xmqqfutpoepz.fsf@gitster.mtv.corp.google.com","threadId":"42248","inReplyTo":"20160510190652.GI7907@onerussian.com","subject":"Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-10T20:11:36Z","receivedAt":"2016-05-10T20:11:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko writes:\n\n> On Fri, 06 May 2016, Yaroslav Halchenko wrote:\n>\n>> Dear Git Folks,\n>\n>> Originally this issue was mentioned in previous thread [1], and I have decided\n>> to bring it into a separate thread. ATM there is a dichotomy in git behavior\n>> between cloning non-bare repos: if I clone over ssh or just locally by\n>> providing url without trailing /.git, git senses for /.git and works just fine\n>> with ssh or local repositories, but fails for \"dummy\" http ones, the demo\n>> script is here [2] which produces output listed below. From which you can see\n>> that cloning using http URL to the repository without /.git fails (git version\n>> 2.8.1, Debian). As it was noted in [1], concern could have been to not\n>> traverse website since could lead to dangerous places. But .git is under\n>> originating url directory, as well as info/ or HEAD or any other object\n>> accessed by git, so IMHO this concern is not a concern.\n\nI am afraid that the reason why you saw no response is primarily\nbecause nobody is interested in extending dumb commit-walker HTTP\ntransport after the world has largely moved on and abandoned it.\n\nThe necessary update to the client might as simple as using\n$GIVEN_URL/.git/ and attempting the request again after seeing the\nprobe for $GIVEN_URL/info/refs fails.\n"},{"id":"286109","messageId":"CA+P7+xoCmMV01=11GRVsuOSoTPgzSFT-VAeqa1SCcLnzpGcb0Q@mail.gmail.com","threadId":"42248","inReplyTo":"xmqqfutpoepz.fsf@gitster.mtv.corp.google.com","subject":"Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-05-10T20:33:40Z","receivedAt":"2016-05-10T20:33:40Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, May 10, 2016 at 1:11 PM, Junio C Hamano wrote:\n> Yaroslav Halchenko writes:\n>\n>> On Fri, 06 May 2016, Yaroslav Halchenko wrote:\n>>\n>>> Dear Git Folks,\n>>\n>>> Originally this issue was mentioned in previous thread [1], and I have decided\n>>> to bring it into a separate thread. ATM there is a dichotomy in git behavior\n>>> between cloning non-bare repos: if I clone over ssh or just locally by\n>>> providing url without trailing /.git, git senses for /.git and works just fine\n>>> with ssh or local repositories, but fails for \"dummy\" http ones, the demo\n>>> script is here [2] which produces output listed below. From which you can see\n>>> that cloning using http URL to the repository without /.git fails (git version\n>>> 2.8.1, Debian). As it was noted in [1], concern could have been to not\n>>> traverse website since could lead to dangerous places. But .git is under\n>>> originating url directory, as well as info/ or HEAD or any other object\n>>> accessed by git, so IMHO this concern is not a concern.\n>\n> I am afraid that the reason why you saw no response is primarily\n> because nobody is interested in extending dumb commit-walker HTTP\n> transport after the world has largely moved on and abandoned it.\n>\n> The necessary update to the client might as simple as using\n> $GIVEN_URL/.git/ and attempting the request again after seeing the\n> probe for $GIVEN_URL/info/refs fails.\n> --\n\nI know at least Jenkin's Git plugin has a workaround to solve this\nissue that is quite similar.\n\nThanks,\nJake\n"},{"id":"286124","messageId":"20160510221032.GV23764@onerussian.com","threadId":"42248","inReplyTo":"xmqqfutpoepz.fsf@gitster.mtv.corp.google.com","subject":"Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-05-10T22:10:32Z","receivedAt":"2016-05-10T22:10:32Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Tue, 10 May 2016, Jacob Keller wrote:\n> > The necessary update to the client might as simple as using\n> > $GIVEN_URL/.git/ and attempting the request again after seeing the\n> > probe for $GIVEN_URL/info/refs fails.\n> I know at least Jenkin's Git plugin has a workaround to solve this\n> issue that is quite similar.\n\nOn Tue, 10 May 2016, Junio C Hamano wrote:\n\n> >> traverse website since could lead to dangerous places. But .git is under\n> >> originating url directory, as well as info/ or HEAD or any other object\n> >> accessed by git, so IMHO this concern is not a concern.\n\n> I am afraid that the reason why you saw no response is primarily\n> because nobody is interested in extending dumb commit-walker HTTP\n> transport after the world has largely moved on and abandoned it.\n\n> The necessary update to the client might as simple as using\n> $GIVEN_URL/.git/ and attempting the request again after seeing the\n> probe for $GIVEN_URL/info/refs fails.\n\nSure -- workarounds are possible, and we are at the state that many dependent\nprojects seems are doing that already (as above noted Jenkin's Git plugin, smth\nalong the lines probably done by github for https as well). In my case I even\nhave managed to erect a lovely apache rewrite rule which seems to work, so I\ncan just 'git clone --recursive' a collection of 30 submodules without a hiccup\n(we are also interested in .git/annex part here ;) ). Citing here if it\ncomes handy for anyone\n\n # To overcome http://thread.gmane.org/gmane.comp.version-control.git/293777\n # we need to rewrite urls so that there is no need for explicit .git/\n RewriteEngine On\n RewriteCond \"!.*/\\.git/.*\"\n RewriteRule \"(.*?/)((? writes:\n\n>> The necessary update to the client might be as simple as using\n>> $GIVEN_URL/.git/ and attempting the request again after seeing the\n>> probe for $GIVEN_URL/info/refs fails.\n>\n> Sure -- workarounds are possible,...\n\nJust so that there is no misunderstanding, the above was not a\nworkaround but is an outline of an implementation of updated http\nclient shipped with Git.\n"},{"id":"286131","messageId":"20160511004931.GX23764@onerussian.com","threadId":"42248","inReplyTo":"xmqq8tzhmuiz.fsf@gitster.mtv.corp.google.com","subject":"Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-05-11T00:49:31Z","receivedAt":"2016-05-11T00:49:31Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Tue, 10 May 2016, Junio C Hamano wrote:\n> >> The necessary update to the client might be as simple as using\n> >> $GIVEN_URL/.git/ and attempting the request again after seeing the\n> >> probe for $GIVEN_URL/info/refs fails.\n\n> > Sure -- workarounds are possible,...\n\n> Just so that there is no misunderstanding, the above was not a\n> workaround but is an outline of an implementation of updated http\n> client shipped with Git.\n\nah, sorry, I have indeed might have misread it. So we are on the same\npage -- that is I saw also as the tentative implementation ;)\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834 Fax: +1 (603) 646-1419\nWWW: http://www.linkedin.com/in/yarik \n"},{"id":"286288","messageId":"xmqqk2j0jnej.fsf@gitster.mtv.corp.google.com","threadId":"42248","inReplyTo":"20160511004931.GX23764@onerussian.com","subject":"Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-11T21:27:32Z","receivedAt":"2016-05-11T21:27:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko writes:\n\n> On Tue, 10 May 2016, Junio C Hamano wrote:\n>> >> The necessary update to the client might be as simple as using\n>> >> $GIVEN_URL/.git/ and attempting the request again after seeing the\n>> >> probe for $GIVEN_URL/info/refs fails.\n>\n>> > Sure -- workarounds are possible,...\n>\n>> Just so that there is no misunderstanding, the above was not a\n>> workaround but is an outline of an implementation of updated http\n>> client shipped with Git.\n>\n> ah, sorry, I have indeed might have misread it. So we are on the same\n> page -- that is I saw also as the tentative implementation ;)\n\nGood. Now somebody who is interested in seeing that happen (when I\nsaid \"shipped with Git\" above, I meant \"shipped with possible future\nGit\") needs to find (or be) somebody to code that change ;-)\n\nThanks.\n"}]}