{"thread":{"id":"3781","subject":"HTTP repo referencing stale heads (can't clone)","startedAt":"2006-04-03T16:01:48Z","lastAt":"2006-04-05T12:23:06Z","messageCount":11,"participants":["Daniel Drake","Junio C Hamano","Nick Hengeveld","Petr Baudis","Radoslaw Szkodzinski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18291","messageId":"443146EC.7060704@gentoo.org","threadId":"3781","inReplyTo":null,"subject":"HTTP repo referencing stale heads (can't clone)","fromName":"Daniel Drake","fromEmail":"dsd@gentoo.org","sentAt":"2006-04-03T16:01:48Z","receivedAt":"2006-04-03T16:01:48Z","isPatch":false,"sender":{"key":"dsd@gentoo.org","avatar":null},"body":"Hi,\n\nI maintain a small git repo. I upload it over ssh (with git-push) to a \nmachine where it is distributed over http:\n\nhttp://dsd.object4.net/git/zd1211.git/\n\nFor some reason it is no longer possible to clone this repo over http:\n\nwalk 35afe6b3a859242a18812e7485ea8b211e24abaf\nwalk 93d9a9f469282e1e392c16ce571da4c08805e8bb\nerror: Couldn't get \nhttp://dsd.object4.net/git/zd1211.git/refs/heads/softmac-old for \nheads/softmac-old\nThe requested URL returned error: 404\nerror: Could not interpret heads/softmac-old as something to pull\n\n\"softmac-old\" is an old branch, which I have recently deleted. I deleted \nit by removing the .git/refs/heads/softmac-old file, and relying on \ngit-prune to clear out old objects.\n\nEven on the server-side, there is no obvious reference to this old head:\n\n$ find -name '*softmac*'\n$ grep -R softmac *\n(no results for either)\n\n\"git-fsck-objects\" reports nothing, \"git-fsck-objects --full\" reports:\ndangling commit 7cc423c942975005f96f308186537ad6e7808c2e\ndangling commit b36378de6231f1b5100b1517b9c8c243a21090fd\n\nI have tried running git-prune and git-update-server-info, but that \ndoesn't help.\n\nAny ideas? I'm still new to git.\nI am running git-1.2.4\n\nThanks,\nDaniel\n"},{"id":"18295","messageId":"7virpqefp1.fsf@assigned-by-dhcp.cox.net","threadId":"3781","inReplyTo":"443146EC.7060704@gentoo.org","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-03T17:23:22Z","receivedAt":"2006-04-03T17:23:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Drake <dsd@gentoo.org> writes:\n\n> I maintain a small git repo. I upload it over ssh (with git-push) to a\n> machine where it is distributed over http:\n>\n> http://dsd.object4.net/git/zd1211.git/\n>...\n> I have tried running git-prune and git-update-server-info, but that\n> doesn't help.\n>\n> Any ideas?\n\nMy standard answer would be\n\nhttp-server$ cd /var/www/git/zd1211.git/ ;# or whereever\nhttp-server$ GIT_DIR=. git-update-server-info\n\nbut you said you have run it already...  Can you try to see if\nthere is some caching proxy involved that still serves stale\ninfo/refs file?\n\nclient$ wget http://dsd.object4.net/git/zd1211.git/info/refs\n"},{"id":"18296","messageId":"20060403180929.GA14967@reactrix.com","threadId":"3781","inReplyTo":"7virpqefp1.fsf@assigned-by-dhcp.cox.net","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-04-03T18:09:30Z","receivedAt":"2006-04-03T18:09:30Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Mon, Apr 03, 2006 at 10:23:22AM -0700, Junio C Hamano wrote:\n\n> My standard answer would be\n> \n> http-server$ cd /var/www/git/zd1211.git/ ;# or whereever\n> http-server$ GIT_DIR=. git-update-server-info\n\nIs there any interest in making the HTTP transport slighly less dumb by\nusing DAV?\n\nI have a working patch to http-fetch that tries to use PROPFIND to get a\nremote pack list and falls back to using objects/info/packs.  It's\nfeasible to do something similar to get a remote ref list when cloning,\nalthough that's a bit more work as all refs would have to be fetched\ninto a local repo and parsed to determine the object type.\n\nLong term, this could give a repo admin the choice of either making sure\ngit-update-server-info has been run after every ref/pack change or\nenabling DAV once.  Assuming they need to use HTTP.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"18297","messageId":"4431694C.4000007@gentoo.org","threadId":"3781","inReplyTo":"7virpqefp1.fsf@assigned-by-dhcp.cox.net","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Daniel Drake","fromEmail":"dsd@gentoo.org","sentAt":"2006-04-03T18:28:28Z","receivedAt":"2006-04-03T18:28:28Z","isPatch":false,"sender":{"key":"dsd@gentoo.org","avatar":null},"body":"Junio C Hamano wrote:\n> client$ wget http://dsd.object4.net/git/zd1211.git/info/refs\n\nAh, should have known. I am behind a (lame) transparent proxy on port 80.\n\nI opened that file in my web browser and it showed the old heads. After \na force-refresh (ctrl+F5, which sends some additionally http headers to \nrefresh the page from the real server), the old heads disappeared, and \ngit now clones successfully.\n\ngit-http-fetch should probably send those extra headers too. I'll try to \nfind some time to look at this next week.\n\nThanks!\nDaniel\n"},{"id":"18327","messageId":"7vzmj1aklh.fsf@assigned-by-dhcp.cox.net","threadId":"3781","inReplyTo":"20060403180929.GA14967@reactrix.com","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-04T07:03:22Z","receivedAt":"2006-04-04T07:03:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld <nickh@reactrix.com> writes:\n\n> Is there any interest in making the HTTP transport slighly less dumb by\n> using DAV?\n\nI personally feel PROPFIND is the right way to do \"wget -r\", and\nvery much welcome a patch to replace objects/info/packs with it\nwhen able.\n\n> I have a working patch to http-fetch that tries to use PROPFIND to get a\n> remote pack list and falls back to using objects/info/packs.  It's\n> feasible to do something similar to get a remote ref list when cloning,\n> although that's a bit more work as all refs would have to be fetched\n> into a local repo and parsed to determine the object type.\n\nFaking info/refs with PROPFIND, if we do not have to peel the\nonion ^{}, should be relatively cheap operation, and could be\ndone as an enhancement to git-ls-remote.sh.  If your faked\ninfo/refs file lacks ^{} entries, git-fetch cannot auto-follow\ntags, but git-clone should work as before.\n\nA clever sysadmins could mod_rewrite requests to info/refs and\nobjects/info/packs with a custom CGI, but then probably they\nwould be running git-daemon ;-).\n"},{"id":"18334","messageId":"20060404100035.GM27689@pasky.or.cz","threadId":"3781","inReplyTo":"20060403180929.GA14967@reactrix.com","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-04-04T10:00:35Z","receivedAt":"2006-04-04T10:00:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Apr 03, 2006 at 08:09:30PM CEST, I got a letter\nwhere Nick Hengeveld <nickh@reactrix.com> said that...\n> Long term, this could give a repo admin the choice of either making sure\n> git-update-server-info has been run after every ref/pack change or\n> enabling DAV once.  Assuming they need to use HTTP.\n\nWell, what is the actual advantage of DAV compared to\ngit-update-server-info? Why would I prefer enabling DAV?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time.  I think\nI have forgotten this before.\n"},{"id":"18340","messageId":"20060404121056.GB14967@reactrix.com","threadId":"3781","inReplyTo":"20060404100035.GM27689@pasky.or.cz","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-04-04T12:10:57Z","receivedAt":"2006-04-04T12:10:57Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:\n\n> Well, what is the actual advantage of DAV compared to\n> git-update-server-info? Why would I prefer enabling DAV?\n\nIn theory, things should work the same either way.  It seems that in\npractice though, the server info files continue to surface as a source\nof fetch problems.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"18343","messageId":"20060404152737.GN27689@pasky.or.cz","threadId":"3781","inReplyTo":"20060404121056.GB14967@reactrix.com","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-04-04T15:27:37Z","receivedAt":"2006-04-04T15:27:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 04, 2006 at 02:10:57PM CEST, I got a letter\nwhere Nick Hengeveld <nickh@reactrix.com> said that...\n> On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:\n> \n> > Well, what is the actual advantage of DAV compared to\n> > git-update-server-info? Why would I prefer enabling DAV?\n> \n> In theory, things should work the same either way.  It seems that in\n> practice though, the server info files continue to surface as a source\n> of fetch problems.\n\nBecause people do not know they have to set up their post-update hook.\nWhen they are already going at lengths to find out how to set up DAV for\ngit fetch, they would discover the post-update hook way as well.\n\nSo, it really seems rather redundant to me.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time.  I think\nI have forgotten this before.\n"},{"id":"18349","messageId":"20060404175640.GE14967@reactrix.com","threadId":"3781","inReplyTo":"20060404152737.GN27689@pasky.or.cz","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-04-04T17:56:40Z","receivedAt":"2006-04-04T17:56:40Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Tue, Apr 04, 2006 at 05:27:37PM +0200, Petr Baudis wrote:\n\n> Because people do not know they have to set up their post-update hook.\n> When they are already going at lengths to find out how to set up DAV for\n> git fetch, they would discover the post-update hook way as well.\n\nThere are other reasons that a client can end up with a stale copy of\nthe server info files - in this case the problem was an intermediate\nproxy out of the control of the repo admin.\n\nWhile we should be able to fix that particular problem, it seems safer\nto go straight to the source if possible.\n\n> So, it really seems rather redundant to me.\n\nIf I've already enabled DAV for pushing to a repo, I'd find it nice to\nbe able to use it for fetches as well.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"18350","messageId":"20060404180130.GF14967@reactrix.com","threadId":"3781","inReplyTo":"4431694C.4000007@gentoo.org","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-04-04T18:01:30Z","receivedAt":"2006-04-04T18:01:30Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Mon, Apr 03, 2006 at 07:28:28PM +0100, Daniel Drake wrote:\n\n> Ah, should have known. I am behind a (lame) transparent proxy on port 80.\n> \n> I opened that file in my web browser and it showed the old heads. After \n> a force-refresh (ctrl+F5, which sends some additionally http headers to \n> refresh the page from the real server), the old heads disappeared, and \n> git now clones successfully.\n> \n> git-http-fetch should probably send those extra headers too. I'll try to \n> find some time to look at this next week.\n\ngit-http-fetch uses the \"Pragma: no-cache\" header when requesting\nobjects that shouldn't be cached.  Is this the additional header you're\nreferring to?\n\nThis patch adds the header to git-ls-remote for the info/refs request.\n\n\ngit-ls-remote: send no-cache header when fetching info/refs\n\nProxies should not cache this file as it can cause a client to end up with\na stale version, as reported here:\n\nhttp://marc.theaimsgroup.com/?l=git&m=114407944125389\n\nSigned-off-by: Nick Hengeveld <nickh@reactrix.com>\n\n\n---\n\n git-ls-remote.sh |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\nda9b6fa01f1a8bd6ab5f6d4346584f3f032584aa\ndiff --git a/git-ls-remote.sh b/git-ls-remote.sh\nindex 2c9a588..b6882a9 100755\n--- a/git-ls-remote.sh\n+++ b/git-ls-remote.sh\n@@ -53,7 +53,7 @@ http://* | https://* )\n         if [ -n \"$GIT_SSL_NO_VERIFY\" ]; then\n             curl_extra_args=\"-k\"\n         fi\n-\tcurl -nsf $curl_extra_args \"$peek_repo/info/refs\" ||\n+\tcurl -nsf $curl_extra_args --header \"Pragma: no-cache\" \"$peek_repo/info/refs\" ||\n \t\techo \"failed\tslurping\"\n \t;;\n \n-- \n1.3.0.rc1.g9aef-dirty\n"},{"id":"18378","messageId":"4433B6AA.6070407@o2.pl","threadId":"3781","inReplyTo":"20060404180130.GF14967@reactrix.com","subject":"Re: HTTP repo referencing stale heads (can't clone)","fromName":"Radoslaw Szkodzinski","fromEmail":"astralstorm@o2.pl","sentAt":"2006-04-05T12:23:06Z","receivedAt":"2006-04-05T12:23:06Z","isPatch":false,"sender":{"key":"astralstorm@o2.pl","avatar":null},"body":"Nick Hengeveld wrote:\n> On Mon, Apr 03, 2006 at 07:28:28PM +0100, Daniel Drake wrote:\n> \n>> Ah, should have known. I am behind a (lame) transparent proxy on port 80.\n>>\n>> I opened that file in my web browser and it showed the old heads. After \n>> a force-refresh (ctrl+F5, which sends some additionally http headers to \n>> refresh the page from the real server), the old heads disappeared, and \n>> git now clones successfully.\n>>\n>> git-http-fetch should probably send those extra headers too. I'll try to \n>> find some time to look at this next week.\n> \n> git-http-fetch uses the \"Pragma: no-cache\" header when requesting\n> objects that shouldn't be cached.  Is this the additional header you're\n> referring to?\n> \n\nAs per HTTP 1.1, it should also send:\nCache-Control: no-cache\n\nPragma: no-cache is the deprecated extension.\nIt's safe to send both.\n\n-- \nGPG Key id:  0xD1F10BA2\nFingerprint: 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2\n\nAstralStorm\n\n"}]}