{"thread":{"id":"41436","subject":"failed submodule update re-run results in no checked out files?","startedAt":"2016-02-17T23:54:28Z","lastAt":"2016-02-18T00:26:19Z","messageCount":3,"participants":["Jacob Keller","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"278520","messageId":"CA+P7+xoF1Rz_43-v3NzGk1Hxp=yhF3toh1nFNQFMRVWr5q8STg@mail.gmail.com","threadId":"41436","inReplyTo":null,"subject":"failed submodule update re-run results in no checked out files?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-02-17T23:54:28Z","receivedAt":"2016-02-17T23:54:28Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"Hi,\n\nI am having an issue currently when using Git with a remote server\nwhich has a limited number of ssh connections.\n\nThe ssh server sometimes closes connections due to too many concurrent\nconnections. I will get the following output from git in this case\nwhen performing a submodule update of a submodule which is not yet\ncurrently cloned/checked out.\n\nstdout: Cloning into 'src/SHARED'...\n\nstderr: Total 10288 (delta 7577), reused 10190 (delta 7577)\nReceived disconnect from 10.96.8.71: 7: Too many concurrent connections\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\nUnable to fetch in submodule path 'src/SHARED'\n\nThe submodule is not cloned successfully, and this occurs somewhere in\nthe middle of the process.\n\nIf I run the command a 2nd time,\n\ngit submodule update --remote src/SHARED,\n\nI get a successful run, but the files are not actually checked out. I\nbelieve this is because the clone that failed did succeed in getting\nthe repository into a state where all the files are \"removed\" so a\nfurther submodule update will do nothing since it's \"already\" checked\nout at the correct commit.\n\nAm I right in my understanding? Is this a bug? I believe I can fix\nthis using --force.\n\nNote that i don't yet currently have a reliable reproduction of this\nfor various reasons, not least of which is that simulating network\nerror is difficult.\n\nAny thoughts on this? Should I just have my script that runs my\ncontinuous integration builds add a check to ensure files are checked\nout? Is \"--force\" enough to get the submodule to be re-checked out\neven if it's already checked out at the location?\n\nThanks,\nJake\n"},{"id":"278521","messageId":"CAGZ79kaM5JREvfCmNMn8FQm1mutmDB3e8DYmtxMEzmUO5mqccw@mail.gmail.com","threadId":"41436","inReplyTo":"CA+P7+xoF1Rz_43-v3NzGk1Hxp=yhF3toh1nFNQFMRVWr5q8STg@mail.gmail.com","subject":"Re: failed submodule update re-run results in no checked out files?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-02-18T00:15:12Z","receivedAt":"2016-02-18T00:15:12Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Feb 17, 2016 at 3:54 PM, Jacob Keller <jacob.keller@gmail.com> wrote:\n> Hi,\n>\n> I am having an issue currently when using Git with a remote server\n> which has a limited number of ssh connections.\n>\n> The ssh server sometimes closes connections due to too many concurrent\n> connections. I will get the following output from git in this case\n> when performing a submodule update of a submodule which is not yet\n> currently cloned/checked out.\n>\n> stdout: Cloning into 'src/SHARED'...\n\nWhich version of Git are you using?\n(does it include origin/sb/submodule-parallel-update, which rewrites\nlots of the relevant code? Also it introduces parallelism, which may not be\nanticipated by the server admin)\n\n>\n> stderr: Total 10288 (delta 7577), reused 10190 (delta 7577)\n\nSeeing both stdout and stderr, I assume you're on master or even behind that,\nwhich doesn't include the rewrite.\n\n> Received disconnect from 10.96.8.71: 7: Too many concurrent connections\n> fatal: Could not read from remote repository.\n>\n> Please make sure you have the correct access rights\n> and the repository exists.\n> Unable to fetch in submodule path 'src/SHARED'\n>\n> The submodule is not cloned successfully, and this occurs somewhere in\n> the middle of the process.\n\nI wonder if the client should retry each submodule at least once, in case of\ntransient errors such as this ssh config having too many connections.\n\n>\n> If I run the command a 2nd time,\n>\n> git submodule update --remote src/SHARED,\n>\n> I get a successful run, but the files are not actually checked out.\n\nThe submodules are cloned via clone --no-checkout.\nThis is because you may have a custom update strategy configured,\n(or a preset such as \"none\" which would clone but do nothing further)\n\n> I\n> believe this is because the clone that failed did succeed in getting\n> the repository into a state where all the files are \"removed\" so a\n> further submodule update will do nothing since it's \"already\" checked\n> out at the correct commit.\n\nyou can pass --force into \"git submodule update\" which passes that\nflag along to the checkout.\n\n>\n> Am I right in my understanding? Is this a bug? I believe I can fix\n> this using --force.\n>\n> Note that i don't yet currently have a reliable reproduction of this\n> for various reasons, not least of which is that simulating network\n> error is difficult.\n\nI have a similar problem which I am debugging currently with the\nnew code. (~1000 submodules which may fail randomly; This is\nwhy I wonder about either automated retries or ignoring the errors)\n\n>\n> Any thoughts on this? Should I just have my script that runs my\n> continuous integration builds add a check to ensure files are checked\n> out? Is \"--force\" enough to get the submodule to be re-checked out\n> even if it's already checked out at the location?\n\nI believe so.\n\nStefan\n\n>\n> Thanks,\n> Jake\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"278522","messageId":"CA+P7+xqj2i7EFpOhsecRPniHL68sEcmnaCB+m6VuO4U3dfnwog@mail.gmail.com","threadId":"41436","inReplyTo":"CAGZ79kaM5JREvfCmNMn8FQm1mutmDB3e8DYmtxMEzmUO5mqccw@mail.gmail.com","subject":"Re: failed submodule update re-run results in no checked out files?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-02-18T00:26:19Z","receivedAt":"2016-02-18T00:26:19Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Feb 17, 2016 at 4:15 PM, Stefan Beller <sbeller@google.com> wrote:\n> On Wed, Feb 17, 2016 at 3:54 PM, Jacob Keller <jacob.keller@gmail.com> wrote:\n>> Hi,\n>>\n>> I am having an issue currently when using Git with a remote server\n>> which has a limited number of ssh connections.\n>>\n>> The ssh server sometimes closes connections due to too many concurrent\n>> connections. I will get the following output from git in this case\n>> when performing a submodule update of a submodule which is not yet\n>> currently cloned/checked out.\n>>\n>> stdout: Cloning into 'src/SHARED'...\n>\n> Which version of Git are you using?\n> (does it include origin/sb/submodule-parallel-update, which rewrites\n> lots of the relevant code? Also it introduces parallelism, which may not be\n> anticipated by the server admin)\n>\n\nI am not 100% sure, but multiple versions. I have multiple virtual\nmachines that run automated tests, and I have not kept all the VMs up\nto date.\n\n>>\n>> stderr: Total 10288 (delta 7577), reused 10190 (delta 7577)\n>\n> Seeing both stdout and stderr, I assume you're on master or even behind that,\n> which doesn't include the rewrite.\n>\n\nI think I am using 2.4.x right now.\n\n>> Received disconnect from 10.96.8.71: 7: Too many concurrent connections\n>> fatal: Could not read from remote repository.\n>>\n>> Please make sure you have the correct access rights\n>> and the repository exists.\n>> Unable to fetch in submodule path 'src/SHARED'\n>>\n>> The submodule is not cloned successfully, and this occurs somewhere in\n>> the middle of the process.\n>\n> I wonder if the client should retry each submodule at least once, in case of\n> transient errors such as this ssh config having too many connections.\n>\n\nWell, in my case it wouldn't be \"transient\" and my process already\ndoes an automatic re-run when it fails. (Technically I am using the\nJava wrapper around CLI Git for Jenkins, which does this re-wrapping).\nIt is possible something is wrong in the java wrapper, but I\ndetermined that it boils down to this sequence. I have yet to be able\nto reproduce a failure locally though without the Java wrapper (due to\nbeing difficult to generate enough simultaneous connections to cause\nthe failure).\n\n>>\n>> If I run the command a 2nd time,\n>>\n>> git submodule update --remote src/SHARED,\n>>\n>> I get a successful run, but the files are not actually checked out.\n>\n> The submodules are cloned via clone --no-checkout.\n> This is because you may have a custom update strategy configured,\n> (or a preset such as \"none\" which would clone but do nothing further)\n>\n\nI see.\n\n>> I\n>> believe this is because the clone that failed did succeed in getting\n>> the repository into a state where all the files are \"removed\" so a\n>> further submodule update will do nothing since it's \"already\" checked\n>> out at the correct commit.\n>\n> you can pass --force into \"git submodule update\" which passes that\n> flag along to the checkout.\n>\n\nRight, this is what worked as a workaround for me.\n\n>>\n>> Am I right in my understanding? Is this a bug? I believe I can fix\n>> this using --force.\n>>\n>> Note that i don't yet currently have a reliable reproduction of this\n>> for various reasons, not least of which is that simulating network\n>> error is difficult.\n>\n> I have a similar problem which I am debugging currently with the\n> new code. (~1000 submodules which may fail randomly; This is\n> why I wonder about either automated retries or ignoring the errors)\n>\n>>\n>> Any thoughts on this? Should I just have my script that runs my\n>> continuous integration builds add a check to ensure files are checked\n>> out? Is \"--force\" enough to get the submodule to be re-checked out\n>> even if it's already checked out at the location?\n>\n> I believe so.\n>\n> Stefan\n>\n\nOk, sounds like for now I need to extend my setup to use --force\ninstead, which will resolve the issue for me. I like the idea of\nhaving git itself perform some retries incase of transient failures\nthough.\n\n>>\n>> Thanks,\n>> Jake\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}