{"thread":{"id":"44352","subject":"RFC Failover url for fetches?","startedAt":"2016-10-21T18:19:55Z","lastAt":"2016-10-24T16:54:49Z","messageCount":4,"participants":["Stefan Beller","Junio C Hamano","Jakub Narębski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"304634","messageId":"CAGZ79kaPdSfY_DXL6BDQ9pAma8p61r4m1n81VTxPHYi8zQuZfA@mail.gmail.com","threadId":"44352","inReplyTo":null,"subject":"RFC Failover url for fetches?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-21T18:19:42Z","receivedAt":"2016-10-21T18:19:55Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"So when pushing it is possible to have multiple urls\n(remote..url) configured.\n\nWhen fetching only the first configured url is considered.\nWould it make sense to allow multiple urls and\ntry them one by one until one works?\n\nBackground:\nhttp://www.businessinsider.com/amazon-spotify-twitter-github-and-etsy-down-in-apparent-dns-attack-2016-10\n\nI wanted to fetch and had to fix a url of a repo\nto point to a working mirror.\n\nThanks,\nStefan\n"},{"id":"304640","messageId":"xmqqeg39bk40.fsf@gitster.mtv.corp.google.com","threadId":"44352","inReplyTo":"CAGZ79kaPdSfY_DXL6BDQ9pAma8p61r4m1n81VTxPHYi8zQuZfA@mail.gmail.com","subject":"Re: RFC Failover url for fetches?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-21T19:03:11Z","receivedAt":"2016-10-21T19:03:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> So when pushing it is possible to have multiple urls\n> (remote..url) configured.\n>\n> When fetching only the first configured url is considered.\n> Would it make sense to allow multiple urls and\n> try them one by one until one works?\n\nI do not think the two are related. Pushing to multiple is not \"I\nwant to update at least one of them\" in the first place.\n\nAs to fetching from two or more places as \"fallback\", I am\nmoderately negative to add it as a dumb feature that does nothing\nmore than \"My fetch from A failed, so let's blindly try it from B\".\nI'd prefer to keep the \"My fetch from A is failing\" knowledge near\nthe surface of end user's consciousness as a mechanism to pressure A\nto fix it--that way everybody who is fetching from A benefits.\nAfter all, doing \"git remote add B\" once (you'd need to tell the URL\nfor B anyway to Git) and issuing \"git fetch B\" after seeing your\nregular \"git fetch\" fails once in a blue moon is not all that\ncumbersome, I would think.\n\nSome people _may_ have objection based on A and B going out of sync,\nespecially B may fall behind even yourself and cause non-ff errors,\nbut I personally am not worried about that, because when somebody\nconfigures B as a fallback for A, there is an expectation that B is\nkept reasonably up to date. It would be a problem if some refs are\nexpected to be constantly rewound at A (e.g. 'pu' in my tree) and\nconfigured to always force-fetch, though. A stale B would silently\nset such a branch in your repository back without failing.\n\n\n\n"},{"id":"304763","messageId":"7fdaa160-9262-5d52-7035-8362ca94beea@gmail.com","threadId":"44352","inReplyTo":"xmqqeg39bk40.fsf@gitster.mtv.corp.google.com","subject":"Re: RFC Failover url for fetches?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-10-23T17:40:57Z","receivedAt":"2016-10-23T17:41:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 21.10.2016 o 21:03, Junio C Hamano pisze:\n> Stefan Beller writes:\n> \n>> So when pushing it is possible to have multiple urls\n>> (remote..url) configured.\n>>\n>> When fetching only the first configured url is considered.\n>> Would it make sense to allow multiple urls and\n>> try them one by one until one works?\n> \n> I do not think the two are related. Pushing to multiple is not \"I\n> want to update at least one of them\" in the first place.\n\nPush is/should be 'update all', fetch is/should be 'fetch any'.\nI thought that multiple remote..url values provide this\nfallback for fetch, but it looks like it isn't so...\n\n> \n> As to fetching from two or more places as \"fallback\", I am\n> moderately negative to add it as a dumb feature that does nothing\n> more than \"My fetch from A failed, so let's blindly try it from B\".\n> I'd prefer to keep the \"My fetch from A is failing\" knowledge near\n> the surface of end user's consciousness as a mechanism to pressure A\n> to fix it--that way everybody who is fetching from A benefits.\n> After all, doing \"git remote add B\" once (you'd need to tell the URL\n> for B anyway to Git) and issuing \"git fetch B\" after seeing your\n> regular \"git fetch\" fails once in a blue moon is not all that\n> cumbersome, I would think.\n\nOne would need to configure fallback B remote to use the same\nremote-branch namespace as remote A, if it is to be used as fallback,\nI would think.\n\n> \n> Some people _may_ have objection based on A and B going out of sync,\n> especially B may fall behind even yourself and cause non-ff errors,\n> but I personally am not worried about that, because when somebody\n> configures B as a fallback for A, there is an expectation that B is\n> kept reasonably up to date. It would be a problem if some refs are\n> expected to be constantly rewound at A (e.g. 'pu' in my tree) and\n> configured to always force-fetch, though. A stale B would silently\n> set such a branch in your repository back without failing.\n\nNb. there is also http-alternates mechanism... which nowadays doesn't\nmatter anyway, I would think.\n\n-- \nJakub Narębski\n\n"},{"id":"304777","messageId":"xmqq1sz58z74.fsf@gitster.mtv.corp.google.com","threadId":"44352","inReplyTo":"7fdaa160-9262-5d52-7035-8362ca94beea@gmail.com","subject":"Re: RFC Failover url for fetches?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-24T16:54:39Z","receivedAt":"2016-10-24T16:54:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narębski writes:\n\n>> As to fetching from two or more places as \"fallback\", I am\n>> moderately negative to add it as a dumb feature that does nothing\n>> more than \"My fetch from A failed, so let's blindly try it from B\".\n>> I'd prefer to keep the \"My fetch from A is failing\" knowledge near\n>> the surface of end user's consciousness as a mechanism to pressure A\n>> to fix it--that way everybody who is fetching from A benefits.\n>> After all, doing \"git remote add B\" once (you'd need to tell the URL\n>> for B anyway to Git) and issuing \"git fetch B\" after seeing your\n>> regular \"git fetch\" fails once in a blue moon is not all that\n>> cumbersome, I would think.\n>\n> One would need to configure fallback B remote to use the same\n> remote-branch namespace as remote A, if it is to be used as fallback,\n> I would think.\n\nYeah, I left it out because I thought that was obvious, but spelling\nit out explicitly may have helped those who weren't reading carefully.\n\nThanks\n"}]}