{"thread":{"id":"46089","subject":"RFC: Would a config fetch.retryCount make sense?","startedAt":"2017-06-01T12:48:16Z","lastAt":"2017-06-05T14:08:26Z","messageCount":5,"participants":["Lars Schneider","Ben Peart","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"321282","messageId":"6762A30E-C558-4085-943B-AB85EBF18706@gmail.com","threadId":"46089","inReplyTo":null,"subject":"RFC: Would a config fetch.retryCount make sense?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-06-01T12:48:06Z","receivedAt":"2017-06-01T12:48:16Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Hi,\n\nwe occasionally see \"The remote end hung up unexpectedly\" (pkt-line.c:265) \non our `git fetch` calls (most noticeably in our automations). I expect \nrandom network glitches to be the cause.\n\nIn some places we added a basic retry mechanism and I was wondering\nif this could be a useful feature for Git itself.\n\nE.g. a Git config such as \"fetch.retryCount\" or something.\nOr is there something like this in Git already and I missed it?\n\nThanks,\nLars\n"},{"id":"321284","messageId":"cf8ce12b-8d5a-ae03-efd8-0f82ea40fce7@gmail.com","threadId":"46089","inReplyTo":"6762A30E-C558-4085-943B-AB85EBF18706@gmail.com","subject":"Re: RFC: Would a config fetch.retryCount make sense?","fromName":"Ben Peart","fromEmail":"peartben@gmail.com","sentAt":"2017-06-01T13:33:27Z","receivedAt":"2017-06-01T13:33:34Z","isPatch":false,"sender":{"key":"benpeart@microsoft.com","avatar":"https://avatars.githubusercontent.com/u/15252029?v=4"},"body":"\n\nOn 6/1/2017 8:48 AM, Lars Schneider wrote:\n> Hi,\n> \n> we occasionally see \"The remote end hung up unexpectedly\" (pkt-line.c:265)\n> on our `git fetch` calls (most noticeably in our automations). I expect\n> random network glitches to be the cause.\n> \n> In some places we added a basic retry mechanism and I was wondering\n> if this could be a useful feature for Git itself.\n> \n\nHaving a configurable retry mechanism makes sense especially if it \nallows continuing an in-progress download rather than aborting and \ntrying over.  I would make it off by default so that any existing higher \nlevel retry mechanism doesn't trigger a retry storm if the problem isn't \na transient network glitch.\n\nInternally we use a tool \n(https://github.com/Microsoft/GVFS/tree/master/GVFS/FastFetch) to \nperform fetch for our build machines.  It has several advantages \nincluding retries when downloading pack files.\n\nIt's biggest advantage is that it uses multiple threads to parallelize \nthe entire fetch and checkout operation from end to end (ie the download \nhappens in parallel as well as checkout happening in parallel with the \ndownload) which makes it take a fraction of the overall time.\n\nWhen time permits, I hope to bring some of these enhancements over into \ngit itself.\n\n> E.g. a Git config such as \"fetch.retryCount\" or something.\n> Or is there something like this in Git already and I missed it?\n> \n> Thanks,\n> Lars\n> \n"},{"id":"321298","messageId":"CAGZ79kZiPgsFaj23QvtgEgUhMiA5ygowY4OorSnzEfCdbv=a7g@mail.gmail.com","threadId":"46089","inReplyTo":"6762A30E-C558-4085-943B-AB85EBF18706@gmail.com","subject":"Re: RFC: Would a config fetch.retryCount make sense?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-01T17:59:40Z","receivedAt":"2017-06-01T17:59:47Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jun 1, 2017 at 5:48 AM, Lars Schneider <larsxschneider@gmail.com> wrote:\n> Hi,\n>\n> we occasionally see \"The remote end hung up unexpectedly\" (pkt-line.c:265)\n> on our `git fetch` calls (most noticeably in our automations). I expect\n> random network glitches to be the cause.\n\nThere is 665b35eccd (submodule--helper: initial clone learns retry\nlogic, 2016-06-09)\nbut that is for submodules and only the initial clone.\n\nI tried searching the mailing list archive if it was discussed for\nfetch before (I am sure it was), but could not find a good hint to link at.\n\nIIRC one major concern was:\n* When a human operates git-fetch, then they want to have fast feedback.\n  The failure may be non-transient, for example when I forgot to up the\n  wifi connection. Then the human can inspect and fix the root cause.\n  (Assumption in human workflow: these non transient errors happen more\n  often than the occasional fetch error due to network glitches.)\n\nFor automation I would expect that the retry logic is actually beneficial,\nsuch that you would want to have a command line options such as\n\"git fetch --retries=5 --delay-between-retries=10s\".\n\n>\n> In some places we added a basic retry mechanism and I was wondering\n> if this could be a useful feature for Git itself.\n\nThere are already retries in other places. :) Cf. f4ab4f3ab1\n(lock_packed_refs():\nallow retries when acquiring the packed-refs lock, 2015-05-11), which\nsolves the need\nof github on the serverside, when they have a very active repo that\nmultiple people\npush to at the same time. (to different branches. I believe that forks\nare internally\nhandled as the same repo, just with different namespaces. So if there\nare 1000 forks\nof linux.git you see a lot of pushes to the \"same\" repo)\n\n>\n> E.g. a Git config such as \"fetch.retryCount\" or something.\n> Or is there something like this in Git already and I missed it?\n\nI like it.\n\nThanks,\nStefan\n"},{"id":"321531","messageId":"9840A095-49EA-4B0C-B318-F86EEF9261B1@gmail.com","threadId":"46089","inReplyTo":"cf8ce12b-8d5a-ae03-efd8-0f82ea40fce7@gmail.com","subject":"Re: RFC: Would a config fetch.retryCount make sense?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-06-05T12:04:55Z","receivedAt":"2017-06-05T12:05:11Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 01 Jun 2017, at 15:33, Ben Peart <peartben@gmail.com> wrote:\n> \n> \n> \n> On 6/1/2017 8:48 AM, Lars Schneider wrote:\n>> Hi,\n>> we occasionally see \"The remote end hung up unexpectedly\" (pkt-line.c:265)\n>> on our `git fetch` calls (most noticeably in our automations). I expect\n>> random network glitches to be the cause.\n>> In some places we added a basic retry mechanism and I was wondering\n>> if this could be a useful feature for Git itself.\n> \n> Having a configurable retry mechanism makes sense especially if it allows continuing an in-progress download rather than aborting and trying over.  I would make it off by default so that any existing higher level retry mechanism doesn't trigger a retry storm if the problem isn't a transient network glitch.\n\nAgreed.\n\n\n> Internally we use a tool (https://github.com/Microsoft/GVFS/tree/master/GVFS/FastFetch) to perform fetch for our build machines.  It has several advantages including retries when downloading pack files.\n\nThat's a \"drop-in\" replacement for \"git fetch\"?! I looked a bit through the \n\"git fetch\" code and retry (especially with continuing in-progress downloads) \nlooks like a bigger change than I expected because of the current \"die() \nin case of error\" implementation.\n\n\n> It's biggest advantage is that it uses multiple threads to parallelize the entire fetch and checkout operation from end to end (ie the download happens in parallel as well as checkout happening in parallel with the download) which makes it take a fraction of the overall time.\n\nInteresting. Do you observe noticeable speed improvements with fetch delta updates,\ntoo? This is usually fast enough for us.\n\nThe people I work with usually complain that the \"clone operation\" is slow. The\nreason is that they clone over and over again to get a \"clean checkout\". I try \nto explain to them in that case that every machine should clone only once and \nthat there are way more efficient ways to get a clean checkout.\n\n\n> When time permits, I hope to bring some of these enhancements over into git itself.\n\nThat would be great!\n\n\n- Lars"},{"id":"321536","messageId":"0bd7b8cd-534a-10ca-78b9-8e041c4c98ec@gmail.com","threadId":"46089","inReplyTo":"9840A095-49EA-4B0C-B318-F86EEF9261B1@gmail.com","subject":"Re: RFC: Would a config fetch.retryCount make sense?","fromName":"Ben Peart","fromEmail":"peartben@gmail.com","sentAt":"2017-06-05T14:08:15Z","receivedAt":"2017-06-05T14:08:26Z","isPatch":false,"sender":{"key":"benpeart@microsoft.com","avatar":"https://avatars.githubusercontent.com/u/15252029?v=4"},"body":"\n\nOn 6/5/2017 8:04 AM, Lars Schneider wrote:\n> \n>> On 01 Jun 2017, at 15:33, Ben Peart <peartben@gmail.com> wrote:\n>>\n>>\n>>\n>> On 6/1/2017 8:48 AM, Lars Schneider wrote:\n>>> Hi,\n>>> we occasionally see \"The remote end hung up unexpectedly\" (pkt-line.c:265)\n>>> on our `git fetch` calls (most noticeably in our automations). I expect\n>>> random network glitches to be the cause.\n>>> In some places we added a basic retry mechanism and I was wondering\n>>> if this could be a useful feature for Git itself.\n>>\n>> Having a configurable retry mechanism makes sense especially if it allows continuing an in-progress download rather than aborting and trying over.  I would make it off by default so that any existing higher level retry mechanism doesn't trigger a retry storm if the problem isn't a transient network glitch.\n> \n> Agreed.\n> \n> \n>> Internally we use a tool (https://github.com/Microsoft/GVFS/tree/master/GVFS/FastFetch) to perform fetch for our build machines.  It has several advantages including retries when downloading pack files.\n> \n> That's a \"drop-in\" replacement for \"git fetch\"?! I looked a bit through the\n> \"git fetch\" code and retry (especially with continuing in-progress downloads)\n> looks like a bigger change than I expected because of the current \"die()\n> in case of error\" implementation.\n> \n\nNo, not a drop in replacement.  We only use this on build machines which \ndon't need history so it only pulls down the tip commit on the initial \nclone.  This is a big win on large repos with a lot of history but not \nso great for a developer machines where history may be desired.\n\n> \n>> It's biggest advantage is that it uses multiple threads to parallelize the entire fetch and checkout operation from end to end (ie the download happens in parallel as well as checkout happening in parallel with the download) which makes it take a fraction of the overall time.\n> \n> Interesting. Do you observe noticeable speed improvements with fetch delta updates,\n> too? This is usually fast enough for us.\n\nSince we have our build machines setup to use it for the clone, we kept \nusing it for delta updates.  When deltas get large (and with thousands \nof developers pushing that can happen pretty quickly) it is still a nice \nperf win.\n\n> \n> The people I work with usually complain that the \"clone operation\" is slow. The\n> reason is that they clone over and over again to get a \"clean checkout\". I try\n> to explain to them in that case that every machine should clone only once and\n> that there are way more efficient ways to get a clean checkout.\n> \n> \n>> When time permits, I hope to bring some of these enhancements over into git itself.\n> \n> That would be great!\n> \n> \n> - Lars\n> \n"}]}