{"thread":{"id":"22541","subject":"upload-pack timing issue on windows?","startedAt":"2010-02-05T23:51:56Z","lastAt":"2010-08-25T20:57:33Z","messageCount":11,"participants":["Erik Faye-Lund","Johannes Sixt","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133761","messageId":"40aa078e1002051551o6d116a50uee3f6a32b16adb46@mail.gmail.com","threadId":"22541","inReplyTo":null,"subject":"upload-pack timing issue on windows?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-05T23:51:56Z","receivedAt":"2010-02-05T23:51:56Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"As some of you might know, I've been working on porting git-daemon to\nWindows for quite some time now. As it stands now, there's really only\none known issue that is blocking on my end here:\n\nSomething weird happens *sometimes* when upload-pack is exiting,\nleading to a client dying with a \"fatal: read error: Invalid\nargument\\nfatal: early EOF\"-error. If I place a sleep(1) at some place\nafter exiting the while(1)-loop in create_pack() in upload-pack.c, the\nsymptom goes away. create_pack() contains some async-code, but this\ndoesn't seem to be triggered in my minimal case at all. I've tried\nflushing stdout and stderr explicitly, no luck.\n\nHow often the issue triggers seems to depend on two things, the size\nof the repo and the connection speed. If I clone from localhost, I\ncan't get it to trigger at all. If the repo is of some size, it\ntriggers rarely. However if I have a repo with only one commit, it\nseems to trigger every single time for me.\n\nI've noticed that one of the last things that happens is a call to\npoll with nfds=1. This triggers a special case in our poll-emulation\non Windows; but removing that special case hasn't given me any\npositive results.\n\nDoes anyone have a hunch about what might trigger this issue?\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"133789","messageId":"201002061106.04305.j6t@kdbg.org","threadId":"22541","inReplyTo":"40aa078e1002051551o6d116a50uee3f6a32b16adb46@mail.gmail.com","subject":"Re: upload-pack timing issue on windows?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-02-06T10:06:04Z","receivedAt":"2010-02-06T10:06:04Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:\n> As some of you might know, I've been working on porting git-daemon to\n> Windows for quite some time now. As it stands now, there's really only\n> one known issue that is blocking on my end here:\n>\n> Something weird happens *sometimes* when upload-pack is exiting,\n> leading to a client dying with a \"fatal: read error: Invalid\n> argument\\nfatal: early EOF\"-error. If I place a sleep(1) at some place\n> after exiting the while(1)-loop in create_pack() in upload-pack.c, the\n> symptom goes away. create_pack() contains some async-code, but this\n> doesn't seem to be triggered in my minimal case at all. I've tried\n> flushing stdout and stderr explicitly, no luck.\n\nI've observed timing related issues in upload-pack as well, but only in the \ncase where the die() is called from the async thread. This is the reason why \nt5530 does not pass.\n\nBut your case seems to be different - i.e. there is no die() involved. Sorry, \ncan't help more...\n\nPerhaps use Procmon to analyse differences among the different successful and \nfailing cases.\n\nTry hacking fetch-pack so that it does not announce side-band(-64k). Perhaps \nit makes a difference.\n\n-- Hannes\n"},{"id":"133794","messageId":"40aa078e1002060401r1dec3c2ate3ddd4f5f5db1e0c@mail.gmail.com","threadId":"22541","inReplyTo":"201002061106.04305.j6t@kdbg.org","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-06T12:01:50Z","receivedAt":"2010-02-06T12:01:50Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sat, Feb 6, 2010 at 11:06 AM, Johannes Sixt <j6t@kdbg.org> wrote:\n> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:\n>> As some of you might know, I've been working on porting git-daemon to\n>> Windows for quite some time now. As it stands now, there's really only\n>> one known issue that is blocking on my end here:\n>>\n>> Something weird happens *sometimes* when upload-pack is exiting,\n>> leading to a client dying with a \"fatal: read error: Invalid\n>> argument\\nfatal: early EOF\"-error. If I place a sleep(1) at some place\n>> after exiting the while(1)-loop in create_pack() in upload-pack.c, the\n>> symptom goes away. create_pack() contains some async-code, but this\n>> doesn't seem to be triggered in my minimal case at all. I've tried\n>> flushing stdout and stderr explicitly, no luck.\n>\n> I've observed timing related issues in upload-pack as well, but only in the\n> case where the die() is called from the async thread. This is the reason why\n> t5530 does not pass.\n>\n> But your case seems to be different - i.e. there is no die() involved. Sorry,\n> can't help more...\n>\n\nYeah, it's probably not the same case, but I certainly do find it\ninteresting that we seemingly have two separate timing-related around\nhere somewhere...\n\n> Perhaps use Procmon to analyse differences among the different successful and\n> failing cases.\n>\n\nI'm not entirely sure what to look for, but I do see that there's\ndifference. There's about 3.5k lines of logging from git.exe,\ngit-daemon.exe and git-upload-pack.exe for the failure case versus\n2.5k for the successful case. And the last sequence of TCP Send in the\nsuccess case is a send of 8 bytes, followed by a send of 212 bytes,\nfollowed again by a send of 1 byte. In the failure case, there's only\na send of 8 bytes in the end. This sequence is reported as sent by\ngit-daemon.exe. In fact, all TCP actions are reported from\ngit-daemon.exe, and apart from the last sequence the lengths are\nreported as identical.\n\n> Try hacking fetch-pack so that it does not announce side-band(-64k). Perhaps\n> it makes a difference.\n>\n\nThis didn't make any difference. I removed \"side-band\" and\n\"side-band-64k\" from capabilities in send_ref() in upload-pack.c, as\nwell as the \"if (server_supports(\"side-band<...>\"-lines in\nbuiltin-fetch-pack.c.\n\nWhile I was at it, I also tried to disable all other capabilities; no luck.\n\nHowever, I have tracked down a bit of what goes on in the client.\nThere's a call to read_in_full, called from pack-write.c, line 246\nthat fails in the failure-case, but not in the success-case. This is\nwhere the client expects \"pack\\tSHA-1\" or \"keep\\tSHA-1\". There \"fatal:\nearly EOF\"-messages seems to originate from index-pack.c, line 197.\nThis is the first line of code in parse_pack_header(), it's also\nAFAICT the first call-site for any read(0, <...>) (though fill()).\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"133832","messageId":"201002062318.59180.j6t@kdbg.org","threadId":"22541","inReplyTo":"40aa078e1002060401r1dec3c2ate3ddd4f5f5db1e0c@mail.gmail.com","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-02-06T22:18:59Z","receivedAt":"2010-02-06T22:18:59Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:\n> However, I have tracked down a bit of what goes on in the client.\n> There's a call to read_in_full, called from pack-write.c, line 246\n> that fails in the failure-case, but not in the success-case. This is\n> where the client expects \"pack\\tSHA-1\" or \"keep\\tSHA-1\". There \"fatal:\n> early EOF\"-messages seems to originate from index-pack.c, line 197.\n> This is the first line of code in parse_pack_header(), it's also\n> AFAICT the first call-site for any read(0, <...>) (though fill()).\n\nThis looks like upload-pack died without sending enough to fill a pack header.\n\nTry merging this branch:\n\n  git://repo.or.cz/git/mingw/j6t.git async-in-thread\n\nIt contains your changes to start_async plus a refinement of die() when it is \ncalled from the async procedure (it passes t5530, for example). It is also \nconverted to pthreads, and therefore also works on Unix. The new \nimplementation of start_async is more careful about the file handles, though \nnot so much on Windows.\n\nIf there's no change for you, then you could look into implementing \nfcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this \nbranch, using Get/SetHandleInformation().\n\nBackground: On Unix, we need FD_CLOEXEC so that the fds that are meant for the \nasync thread do not remain open in an unrelated child process; on Windows, we \nare just lucky and can get away without FD_CLOEXEC because our pipe()s are \nnon-inheritable and async only work with pipes. But once we pass other fds to \nthe async procedure, we need a working FD_CLOEXEC. Perhaps something in this \ndirection is related to your problem.\n\nYou could push out your current state of the git-daemon and a recipe to \nreproduce the problem. Perhaps I find some time to look into it.\n\n-- Hannes\n"},{"id":"133919","messageId":"40aa078e1002080318n16918f91r5a5f4cd9b76a8436@mail.gmail.com","threadId":"22541","inReplyTo":"201002062318.59180.j6t@kdbg.org","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-08T11:18:06Z","receivedAt":"2010-02-08T11:18:06Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sat, Feb 6, 2010 at 11:18 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:\n>> However, I have tracked down a bit of what goes on in the client.\n>> There's a call to read_in_full, called from pack-write.c, line 246\n>> that fails in the failure-case, but not in the success-case. This is\n>> where the client expects \"pack\\tSHA-1\" or \"keep\\tSHA-1\". There \"fatal:\n>> early EOF\"-messages seems to originate from index-pack.c, line 197.\n>> This is the first line of code in parse_pack_header(), it's also\n>> AFAICT the first call-site for any read(0, <...>) (though fill()).\n>\n> This looks like upload-pack died without sending enough to fill a pack header.\n>\n> Try merging this branch:\n>\n>  git://repo.or.cz/git/mingw/j6t.git async-in-thread\n>\n> It contains your changes to start_async plus a refinement of die() when it is\n> called from the async procedure (it passes t5530, for example). It is also\n> converted to pthreads, and therefore also works on Unix. The new\n> implementation of start_async is more careful about the file handles, though\n> not so much on Windows.\n>\n> If there's no change for you, then you could look into implementing\n> fcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this\n> branch, using Get/SetHandleInformation().\n>\n\nThanks a lot. I tried merging it, but the issue still pops up. I also\ntried to implement fcntl(F_GETFD/SETFD, FD_CLOEXEC), still no dice.\nI'm not entirely sure if I did it correctly, though.\n\n> Background: On Unix, we need FD_CLOEXEC so that the fds that are meant for the\n> async thread do not remain open in an unrelated child process; on Windows, we\n> are just lucky and can get away without FD_CLOEXEC because our pipe()s are\n> non-inheritable and async only work with pipes. But once we pass other fds to\n> the async procedure, we need a working FD_CLOEXEC. Perhaps something in this\n> direction is related to your problem.\n>\n> You could push out your current state of the git-daemon and a recipe to\n> reproduce the problem. Perhaps I find some time to look into it.\n>\n\nSure. You can find my current version at\ngit://repo.or.cz/git/kusma.git work/daemon-fcntl\n\nThis branch includes your branch and my fcntl-attempt, as well as an\nalmost-fixed-up version of the last daemon-win32 series I sent out\n(still lacking critical sections when saving process ids, as you\nsuggested).\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"134182","messageId":"76718491002101241y591c63abv403660bd22c814c3@mail.gmail.com","threadId":"22541","inReplyTo":"40aa078e1002080318n16918f91r5a5f4cd9b76a8436@mail.gmail.com","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-02-10T20:41:03Z","receivedAt":"2010-02-10T20:41:03Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 8, 2010 at 6:18 AM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:\n> On Sat, Feb 6, 2010 at 11:18 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n>> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:\n>>> However, I have tracked down a bit of what goes on in the client.\n>>> There's a call to read_in_full, called from pack-write.c, line 246\n>>> that fails in the failure-case, but not in the success-case. This is\n>>> where the client expects \"pack\\tSHA-1\" or \"keep\\tSHA-1\". There \"fatal:\n>>> early EOF\"-messages seems to originate from index-pack.c, line 197.\n>>> This is the first line of code in parse_pack_header(), it's also\n>>> AFAICT the first call-site for any read(0, <...>) (though fill()).\n>>\n>> This looks like upload-pack died without sending enough to fill a pack header.\n>>\n>> Try merging this branch:\n>>\n>>  git://repo.or.cz/git/mingw/j6t.git async-in-thread\n>>\n>> It contains your changes to start_async plus a refinement of die() when it is\n>> called from the async procedure (it passes t5530, for example). It is also\n>> converted to pthreads, and therefore also works on Unix. The new\n>> implementation of start_async is more careful about the file handles, though\n>> not so much on Windows.\n>>\n>> If there's no change for you, then you could look into implementing\n>> fcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this\n>> branch, using Get/SetHandleInformation().\n>>\n>\n> Thanks a lot. I tried merging it, but the issue still pops up. I also\n> tried to implement fcntl(F_GETFD/SETFD, FD_CLOEXEC), still no dice.\n> I'm not entirely sure if I did it correctly, though.\n\nI have no idea if it's related, but a similar thing seems to happen\nwith git under cygwin-1.7.1.\n\nhttp://article.gmane.org/gmane.os.cygwin/114032\n\nThis is when cloning/fetching over ssh. I've not personally seen the\nproblem, but I compile git from source. Coworkers who are using the\ncygwin-1.7.1 provided git see the problem consistently.\n\nj.\n"},{"id":"148726","messageId":"AANLkTimk+SsmiHk7zWCTEeghk3sYjapDCDeZX=TP9UH_@mail.gmail.com","threadId":"22541","inReplyTo":"40aa078e1002080318n16918f91r5a5f4cd9b76a8436@mail.gmail.com","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-08-22T23:27:41Z","receivedAt":"2010-08-22T23:27:41Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Feb 8, 2010 at 1:18 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:\n> On Sat, Feb 6, 2010 at 11:18 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n>> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:\n>>> However, I have tracked down a bit of what goes on in the client.\n>>> There's a call to read_in_full, called from pack-write.c, line 246\n>>> that fails in the failure-case, but not in the success-case. This is\n>>> where the client expects \"pack\\tSHA-1\" or \"keep\\tSHA-1\". There \"fatal:\n>>> early EOF\"-messages seems to originate from index-pack.c, line 197.\n>>> This is the first line of code in parse_pack_header(), it's also\n>>> AFAICT the first call-site for any read(0, <...>) (though fill()).\n>>\n>> This looks like upload-pack died without sending enough to fill a pack header.\n>>\n>> Try merging this branch:\n>>\n>>  git://repo.or.cz/git/mingw/j6t.git async-in-thread\n>>\n>> It contains your changes to start_async plus a refinement of die() when it is\n>> called from the async procedure (it passes t5530, for example). It is also\n>> converted to pthreads, and therefore also works on Unix. The new\n>> implementation of start_async is more careful about the file handles, though\n>> not so much on Windows.\n>>\n>> If there's no change for you, then you could look into implementing\n>> fcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this\n>> branch, using Get/SetHandleInformation().\n>>\n>\n> Thanks a lot. I tried merging it, but the issue still pops up. I also\n> tried to implement fcntl(F_GETFD/SETFD, FD_CLOEXEC), still no dice.\n> I'm not entirely sure if I did it correctly, though.\n>\n\nMore than 6 months later, and I've finally bothered to debug this further:\n- The culprit seems to be our poll-emulation. My understanding is that\npoll() was called by create_pack_file() in upload-pack.c with nfds=1\n(it's 2 until one of the fds are closed) when there's no data\navailable in the pipe. Since our poll() always returns POLLIN when\nnfds=1, the check for xread(...) == 0 further down in\ncreate_pack_file() cause the fd to be closed, leading to an error on\nthe client-side.\n-  Just removing the nfds=1-hack works for me, but I'm suspecting the\nnfds=1-hack is there for some socket-reason. So instead I've replaced\nour poll-emulation with gnulib's in my branch (with a couple of\npatches on top), and it seems to do the trick for me. I still haven't\ntested it heavily, though.\n- The easiest way I've found to debug the issue, is to use git-fetch\nfrom localhost with a repo with a single commit with a single, empty\nfile. Doing this triggers the bug every time for me, and doesn't hide\nwhat's going on as much as git-clone does.\n\nThe latest version of my branch can be found here:\nhttp://repo.or.cz/w/git/kusma.git/shortlog/refs/heads/work/daemon-win32-process\n"},{"id":"148864","messageId":"201008242124.23890.j6t@kdbg.org","threadId":"22541","inReplyTo":"AANLkTimk+SsmiHk7zWCTEeghk3sYjapDCDeZX=TP9UH_@mail.gmail.com","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-08-24T19:24:23Z","receivedAt":"2010-08-24T19:24:23Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Montag, 23. August 2010, Erik Faye-Lund wrote:\n> - The culprit seems to be our poll-emulation. My understanding is that\n> poll() was called by create_pack_file() in upload-pack.c with nfds=1\n> (it's 2 until one of the fds are closed) when there's no data\n> available in the pipe. Since our poll() always returns POLLIN when\n> nfds=1, the check for xread(...) == 0 further down in\n> create_pack_file() cause the fd to be closed, leading to an error on\n> the client-side.\n> -  Just removing the nfds=1-hack works for me, but I'm suspecting the\n> nfds=1-hack is there for some socket-reason. So instead I've replaced\n> our poll-emulation with gnulib's in my branch (with a couple of\n> patches on top), and it seems to do the trick for me. I still haven't\n> tested it heavily, though.\n\nThe nfds == 1 hack is an \"optimization\": When only one channel must be \nobserved, then we can let (x)read() wait for data instead of doing it inside \npoll() in some way.\n\nI'm not happy with our poll emulation because it contains a busy-loop. \nGnulib's version looks quite capable, but I haven't studied it in detail. \nUntil then, I trust that it does the right thing.\n\n--Hannes\n"},{"id":"148974","messageId":"AANLkTinboi+L3fvC___pULO0u_ZBNNOM6er+chxt7s07@mail.gmail.com","threadId":"22541","inReplyTo":"201008242124.23890.j6t@kdbg.org","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-08-25T17:40:40Z","receivedAt":"2010-08-25T17:40:40Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Aug 24, 2010 at 9:24 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n> On Montag, 23. August 2010, Erik Faye-Lund wrote:\n>> - The culprit seems to be our poll-emulation. My understanding is that\n>> poll() was called by create_pack_file() in upload-pack.c with nfds=1\n>> (it's 2 until one of the fds are closed) when there's no data\n>> available in the pipe. Since our poll() always returns POLLIN when\n>> nfds=1, the check for xread(...) == 0 further down in\n>> create_pack_file() cause the fd to be closed, leading to an error on\n>> the client-side.\n>> -  Just removing the nfds=1-hack works for me, but I'm suspecting the\n>> nfds=1-hack is there for some socket-reason. So instead I've replaced\n>> our poll-emulation with gnulib's in my branch (with a couple of\n>> patches on top), and it seems to do the trick for me. I still haven't\n>> tested it heavily, though.\n>\n> The nfds == 1 hack is an \"optimization\": When only one channel must be\n> observed, then we can let (x)read() wait for data instead of doing it inside\n> poll() in some way.\n>\n\nOK, thanks for the clarification. Unfortunately, this optimization\nbreaks down in some cases (like the one I described).\n\n> I'm not happy with our poll emulation because it contains a busy-loop.\n> Gnulib's version looks quite capable, but I haven't studied it in detail.\n> Until then, I trust that it does the right thing.\n>\n\nWell, I've found (and supplied patches for) a couple of bugs in it,\nbut apart from that it seems quite sane. So yeah, I think it might be\nthe best way forward.\n\nBut I'm curious, what's the best way of import a couple of foreign\nsource files, while maintaining a couple of patches on top of them?\nI'm thinking that perhaps a import-commit followed by the patches\nwould make it easier to merge in changes than to just import the\npatched version, but I'm not entirely sure how to do such a merge\nwithout merging a full subtree...\n"},{"id":"148994","messageId":"201008252253.04516.j6t@kdbg.org","threadId":"22541","inReplyTo":"AANLkTinboi+L3fvC___pULO0u_ZBNNOM6er+chxt7s07@mail.gmail.com","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-08-25T20:53:03Z","receivedAt":"2010-08-25T20:53:03Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Mittwoch, 25. August 2010, Erik Faye-Lund wrote:\n> But I'm curious, what's the best way of import a couple of foreign\n> source files, while maintaining a couple of patches on top of them?\n> I'm thinking that perhaps a import-commit followed by the patches\n> would make it easier to merge in changes than to just import the\n> patched version, but I'm not entirely sure how to do such a merge\n> without merging a full subtree...\n\nThis is about only two files. When a new version is available from upstream, \njust branch from the import-commit, apply the two new files, and merge the \nresult.\n\n-- Hannes\n"},{"id":"148997","messageId":"AANLkTimHmFQmgX5q5n=yj3VKpgPFzpnDd0v-RY6bgpfp@mail.gmail.com","threadId":"22541","inReplyTo":"201008252253.04516.j6t@kdbg.org","subject":"Re: [msysGit] upload-pack timing issue on windows?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-08-25T20:57:33Z","receivedAt":"2010-08-25T20:57:33Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Aug 25, 2010 at 10:53 PM, Johannes Sixt <j6t@kdbg.org> wrote:\n> On Mittwoch, 25. August 2010, Erik Faye-Lund wrote:\n>> But I'm curious, what's the best way of import a couple of foreign\n>> source files, while maintaining a couple of patches on top of them?\n>> I'm thinking that perhaps a import-commit followed by the patches\n>> would make it easier to merge in changes than to just import the\n>> patched version, but I'm not entirely sure how to do such a merge\n>> without merging a full subtree...\n>\n> This is about only two files. When a new version is available from upstream,\n> just branch from the import-commit, apply the two new files, and merge the\n> result.\n>\n\nThanks, makes sense.\n"}]}