{"thread":{"id":"33097","subject":"rebase: strange failures to apply patc 3-way","startedAt":"2013-03-07T10:16:50Z","lastAt":"2013-03-12T08:26:51Z","messageCount":27,"participants":["Max Horn","Andrew Wong","John Szakmeister","Jeff King","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210758","messageId":"7A483B92-D671-46CA-9EFD-83C6F4C97B5E@quendi.de","threadId":"33097","inReplyTo":null,"subject":"rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-07T10:16:50Z","receivedAt":"2013-03-07T10:16:50Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"Recently I have observed very strange failures in \"git rebase\" that cause it to fail to work automatically in situations where it should trivially be able to do so.\n\nIn case it matter, here's my setup: git 1.8.2.rc2.4.g7799588 (i.e. git.git master branch) on Mac OS X. The repos clone is on a HFS+ partition, not on a network volume. No gitattributes are being used. Regarding the origin of the repos (I hope it doesn't matter, but just in case): The repository in question used to be a CVS repository; it was decided to switch to Mercurial (not my decision ;-) and I performed the conversion; I first converted it to git using cvs2git (from the cvs2svn suite), then performed some history cleanup, and finally used \"hg convert\" to convert it to git. Recently, I have been accessing the repository from git via the gitifyhg tool . \n\nAnyway, several strange things just happened (and I had similar experiences in the past days and weeks, but that was using an older git, and I thought I was just doing something wrong).\n\nSpecifically, I wanted to rebase a branch with some experimental commits. The strange things started with this:\n\n$ git rebase MY-NEW-BASE\nFirst, rewinding head to replay your work on top of it...\nApplying: SOME COMMIT\nApplying: SOME OTHER COMMIT\n...\nApplying: COMMIT A\nApplying: COMMIT B\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nerror: Your local changes to the following files would be overwritten by merge:\n\tsome/source.file\nPlease, commit your changes or stash them before you can merge.\nAborting\nFailed to merge in the changes.\nPatch failed at 0014 COMMIT B\nThe copy of the patch that failed is found in:\n /path/to/my/repo/.git/rebase-apply/patch\n\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase --abort\".\n\n\nNow, what is strange about this is that the failed patch actually applies cleanly:\n\n$ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch\npatching file some/source.file\n$\n\nAnd there is no subtle merge issue here, either: That patch is the only one to have touched the surrounding code since 1999! There is no source of conflict there!\n\nAnyway. The tale gets stranger, as I was trying to do this again (no changes were made to the repos in between, this is a straight continuation from above):\n\n$ git rebase --abort\n$ git rebase MY-NEW-BASE\nFirst, rewinding head to replay your work on top of it...\nApplying: SOME COMMIT\nApplying: SOME OTHER COMMIT\n...\nApplying: COMMIT A\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nerror: Your local changes to the following files would be overwritten by merge:\n\tsome/othersource.file\n\tsome/yetanother.file\nPlease, commit your changes or stash them before you can merge.\nAborting\nFailed to merge in the changes.\nPatch failed at 0013 COMMIT A\nThe copy of the patch that failed is found in:\n /path/to/my/repo/.git/rebase-apply/patch\n\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase --abort\".\n\n\n\nSo suddenly it fails to apply the commit A, the one before the previously failing commit. Huh? But again, the failing patch applies cleanly (and after all, rebase was able to apply it in my previous attempt). And again, the patch actually applies cleanly. So one more try:\n\n\n$ git rebase --abort\n$ git rebase MY-NEW-BASE\nFirst, rewinding head to replay your work on top of it...\nApplying: SOME COMMIT\nApplying: SOME OTHER COMMIT\n...\nApplying: COMMIT A\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nerror: Your local changes to the following files would be overwritten by merge:\n\tsome/othersource.file\nPlease, commit your changes or stash them before you can merge.\nAborting\nFailed to merge in the changes.\nPatch failed at 0013 COMMIT A\nThe copy of the patch that failed is found in:\n /path/to/my/repo/.git/rebase-apply/patch\n\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase --abort\".\n\n\nAgain it fails in commit A -- but this time, it only thinks one file is problematic. HUH? Again, the patch actually applies cleanly:\n\n$ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch\npatching file some/othersource.file\npatching file some/yetanother.file\n\n\nAt this point, things stabilized, and when I now abort and reattempt the merge, it always fails in the same way. This time trying to apply a change to a code comment that was last changed in 1997 (though for one hunk, a few lines before the changed lines, there is a line that was changed in 2008... but I assure you, that line is there in the ancestors of both the branch I want to rebase, and also in the MY-NEW-BASE branch I rebase onto).\n\n\nSomething seems to be really fishy here and I wonder if anybody has an idea what's going wrong here. Is this a bug in git? Is my repos broken in some way? Note that \"git fsck\" reported nothing except some dangling objects. Any other ideas? \n\n\nCheers,\nMax\n"},{"id":"210832","messageId":"494292C5-EBD9-487B-8846-9D9DD23ACB83@quendi.de","threadId":"33097","inReplyTo":"7A483B92-D671-46CA-9EFD-83C6F4C97B5E@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-08T11:34:55Z","receivedAt":"2013-03-08T11:34:55Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"A follow up:\n\nI was able to reproduce this behavior on my Mac with multiple git versions down to 1.6.0.6. On the other hand, I copied the whole work tree to a virtual machine running Ubuntu, and there the issue did not occur.\n\nAll in all, I suspect that Mac OS X and/or the filesystem (HFS+ with journaling, not case sensitive (the default)) might be at fault. Still, this is quite puzzling and annoying, and so I still wonder if anybody has any insights on this.\n\nAnd: is this a known issue, I wonder?\n\n\nCheers,\nMax\n\n\nOn 07.03.2013, at 11:16, Max Horn wrote:\n\n> Recently I have observed very strange failures in \"git rebase\" that cause it to fail to work automatically in situations where it should trivially be able to do so.\n> \n> In case it matter, here's my setup: git 1.8.2.rc2.4.g7799588 (i.e. git.git master branch) on Mac OS X. The repos clone is on a HFS+ partition, not on a network volume. No gitattributes are being used. Regarding the origin of the repos (I hope it doesn't matter, but just in case): The repository in question used to be a CVS repository; it was decided to switch to Mercurial (not my decision ;-) and I performed the conversion; I first converted it to git using cvs2git (from the cvs2svn suite), then performed some history cleanup, and finally used \"hg convert\" to convert it to git. Recently, I have been accessing the repository from git via the gitifyhg tool . \n> \n> Anyway, several strange things just happened (and I had similar experiences in the past days and weeks, but that was using an older git, and I thought I was just doing something wrong).\n> \n> Specifically, I wanted to rebase a branch with some experimental commits. The strange things started with this:\n> \n> $ git rebase MY-NEW-BASE\n> First, rewinding head to replay your work on top of it...\n> Applying: SOME COMMIT\n> Applying: SOME OTHER COMMIT\n> ...\n> Applying: COMMIT A\n> Applying: COMMIT B\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> error: Your local changes to the following files would be overwritten by merge:\n> \tsome/source.file\n> Please, commit your changes or stash them before you can merge.\n> Aborting\n> Failed to merge in the changes.\n> Patch failed at 0014 COMMIT B\n> The copy of the patch that failed is found in:\n> /path/to/my/repo/.git/rebase-apply/patch\n> \n> When you have resolved this problem, run \"git rebase --continue\".\n> If you prefer to skip this patch, run \"git rebase --skip\" instead.\n> To check out the original branch and stop rebasing, run \"git rebase --abort\".\n> \n> \n> Now, what is strange about this is that the failed patch actually applies cleanly:\n> \n> $ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch\n> patching file some/source.file\n> $\n> \n> And there is no subtle merge issue here, either: That patch is the only one to have touched the surrounding code since 1999! There is no source of conflict there!\n> \n> Anyway. The tale gets stranger, as I was trying to do this again (no changes were made to the repos in between, this is a straight continuation from above):\n> \n> $ git rebase --abort\n> $ git rebase MY-NEW-BASE\n> First, rewinding head to replay your work on top of it...\n> Applying: SOME COMMIT\n> Applying: SOME OTHER COMMIT\n> ...\n> Applying: COMMIT A\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> error: Your local changes to the following files would be overwritten by merge:\n> \tsome/othersource.file\n> \tsome/yetanother.file\n> Please, commit your changes or stash them before you can merge.\n> Aborting\n> Failed to merge in the changes.\n> Patch failed at 0013 COMMIT A\n> The copy of the patch that failed is found in:\n> /path/to/my/repo/.git/rebase-apply/patch\n> \n> When you have resolved this problem, run \"git rebase --continue\".\n> If you prefer to skip this patch, run \"git rebase --skip\" instead.\n> To check out the original branch and stop rebasing, run \"git rebase --abort\".\n> \n> \n> \n> So suddenly it fails to apply the commit A, the one before the previously failing commit. Huh? But again, the failing patch applies cleanly (and after all, rebase was able to apply it in my previous attempt). And again, the patch actually applies cleanly. So one more try:\n> \n> \n> $ git rebase --abort\n> $ git rebase MY-NEW-BASE\n> First, rewinding head to replay your work on top of it...\n> Applying: SOME COMMIT\n> Applying: SOME OTHER COMMIT\n> ...\n> Applying: COMMIT A\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> error: Your local changes to the following files would be overwritten by merge:\n> \tsome/othersource.file\n> Please, commit your changes or stash them before you can merge.\n> Aborting\n> Failed to merge in the changes.\n> Patch failed at 0013 COMMIT A\n> The copy of the patch that failed is found in:\n> /path/to/my/repo/.git/rebase-apply/patch\n> \n> When you have resolved this problem, run \"git rebase --continue\".\n> If you prefer to skip this patch, run \"git rebase --skip\" instead.\n> To check out the original branch and stop rebasing, run \"git rebase --abort\".\n> \n> \n> Again it fails in commit A -- but this time, it only thinks one file is problematic. HUH? Again, the patch actually applies cleanly:\n> \n> $ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch\n> patching file some/othersource.file\n> patching file some/yetanother.file\n> \n> \n> At this point, things stabilized, and when I now abort and reattempt the merge, it always fails in the same way. This time trying to apply a change to a code comment that was last changed in 1997 (though for one hunk, a few lines before the changed lines, there is a line that was changed in 2008... but I assure you, that line is there in the ancestors of both the branch I want to rebase, and also in the MY-NEW-BASE branch I rebase onto).\n> \n> \n> Something seems to be really fishy here and I wonder if anybody has an idea what's going wrong here. Is this a bug in git? Is my repos broken in some way? Note that \"git fsck\" reported nothing except some dangling objects. Any other ideas? \n> \n> \n> Cheers,\n> Max\n> \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> \n"},{"id":"210835","messageId":"CADeaMWp_R0HLwEYn7O3oX4-0OoSeqLfzz_2AYXT-Po88nM4HkQ@mail.gmail.com","threadId":"33097","inReplyTo":"494292C5-EBD9-487B-8846-9D9DD23ACB83@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-08T15:32:49Z","receivedAt":"2013-03-08T15:32:49Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/8/13, Max Horn wrote:\n> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with\n> journaling, not case sensitive (the default)) might be at fault. Still, this\n> is quite puzzling and annoying, and so I still wonder if anybody has any\n> insights on this.\n\nWhen \"rebase\" errors out at COMMIT A, try manually running \"git apply\"\non the patch file (rebase-apply/patch) a couple times, and see if the\nerror occurs randomly. You'd have to do a \"reset --hard\" to revert the\nchanges done by \"git apply\" every time before you run it again. The\nerror from \"git apply\" might shed more light on the issue.\n"},{"id":"210841","messageId":"205D17C4-F737-46E9-BC48-D16D5948C707@quendi.de","threadId":"33097","inReplyTo":"CADeaMWp_R0HLwEYn7O3oX4-0OoSeqLfzz_2AYXT-Po88nM4HkQ@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-08T17:35:46Z","receivedAt":"2013-03-08T17:35:46Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\n\nAm 08.03.2013 um 16:32 schrieb Andrew Wong :\n\n> On 3/8/13, Max Horn wrote:\n>> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with\n>> journaling, not case sensitive (the default)) might be at fault. Still, this\n>> is quite puzzling and annoying, and so I still wonder if anybody has any\n>> insights on this.\n> \n> When \"rebase\" errors out at COMMIT A, try manually running \"git apply\"\n> on the patch file (rebase-apply/patch) a couple times, and see if the\n> error occurs randomly. You'd have to do a \"reset --hard\" to revert the\n> changes done by \"git apply\" every time before you run it again. The\n> error from \"git apply\" might shed more light on the issue.\n\nI tried this a dozen times, but 'git apply' failed to fail even once. No surprise there, given that the patch that throws off rebase every time is clean and simple. I am flabbergasted :-(\n"},{"id":"210846","messageId":"CADgNjan9v++__TSPE55j7+=BBZrVEkMD52O+9kXAm-C8SRV+Ww@mail.gmail.com","threadId":"33097","inReplyTo":"205D17C4-F737-46E9-BC48-D16D5948C707@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-08T18:02:21Z","receivedAt":"2013-03-08T18:02:21Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/8/13, Max Horn wrote:\n> I tried this a dozen times, but 'git apply' failed to fail even once. No\n> surprise there, given that the patch that throws off rebase every time is\n> clean and simple. I am flabbergasted :-(\n\nHm, what if you add in the \"--index\" flag? i.e.\n git apply --index .git/rebase-apply/patch\n\nWonder if that makes any difference...\n"},{"id":"210847","messageId":"B21B6CEC-7507-47A1-9BBB-FB95EA6B831F@quendi.de","threadId":"33097","inReplyTo":"CADgNjan9v++__TSPE55j7+=BBZrVEkMD52O+9kXAm-C8SRV+Ww@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-08T18:47:15Z","receivedAt":"2013-03-08T18:47:15Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\n\nAm 08.03.2013 um 19:02 schrieb Andrew Wong :\n\n> On 3/8/13, Max Horn wrote:\n>> I tried this a dozen times, but 'git apply' failed to fail even once. No\n>> surprise there, given that the patch that throws off rebase every time is\n>> clean and simple. I am flabbergasted :-(\n> \n> Hm, what if you add in the \"--index\" flag? i.e.\n> git apply --index .git/rebase-apply/patch\n> \n> Wonder if that makes any difference...\n\nSame result, it works fine.\n"},{"id":"210848","messageId":"CADgNja=Ej8jnYn027GX986VrmuqVemM7aE59rynHzUpToPVaEw@mail.gmail.com","threadId":"33097","inReplyTo":"B21B6CEC-7507-47A1-9BBB-FB95EA6B831F@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-08T19:20:22Z","receivedAt":"2013-03-08T19:20:22Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/8/13, Max Horn wrote:\n> Same result, it works fine.\n\nJust shooting in the dark here... I wonder if there's some background\nprocess running in OS X that's messing with the files/directories\nwhile rebase is working... backup, virus scan, etc? Or maybe some\nprograms that you're using at the same time? Maybe also make sure you\ndon't have any programs (shells, editors, etc.) opened that's\naccessing those files/directories?\n\nDoes the error always happen at COMMIT A and COMMIT B? Or is it all\nover the place?\n\nIn cases where COMMIT A succeeded, did it say it did a 3-way merge? Or\nwas it exactly as the output in your original message? i.e. no message\nat all\n"},{"id":"210892","messageId":"3B5EA38E-9603-4321-AA3C-74354BBC8BFC@quendi.de","threadId":"33097","inReplyTo":"CADgNja=Ej8jnYn027GX986VrmuqVemM7aE59rynHzUpToPVaEw@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-09T11:26:54Z","receivedAt":"2013-03-09T11:26:54Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 08.03.2013, at 20:20, Andrew Wong wrote:\n\n> On 3/8/13, Max Horn wrote:\n>> Same result, it works fine.\n> \n> Just shooting in the dark here... I wonder if there's some background\n> process running in OS X that's messing with the files/directories\n> while rebase is working... backup, virus scan, etc? Or maybe some\n> programs that you're using at the same time? Maybe also make sure you\n> don't have any programs (shells, editors, etc.) opened that's\n> accessing those files/directories?\n\nI am pretty sure no other programs are accessing those files at the same time. But just to make sure I quite most programs. No virus scanner running. No backup running -- although, OS X automatically runs hourly backups as part of Time Machine... So just to be triple certain, I black listed the repos dir in both the \"Time Machine\" backup service and the \"Spotlight\" indexing service.\n\nNo diference. In the end I even did a reboot, but that made no differences either (which I am quite relieved about, I must say ;-).\n\n\n> \n> Does the error always happen at COMMIT A and COMMIT B? Or is it all\n> over the place?\n\nIt tends to fail in separate places, but eventually \"stabilizes\". E.g. I just did a couple test rebases, and it failed twice in commit 14, then the third time in commit 15 (which underlines once more that the failures are inappropriate).\n\nThe fourth time, something new and weird happened:\n\n$ git rebase --abort\n$ git rebase NEW-PARENT \nCannot rebase: You have unstaged changes.\nPlease commit or stash them.\n$\n\nThis is quite suspicious. It appears that git for some reason things a file is dirty when it isn't. That could explain the other rebase failures too, couldn't it? But what might cause such a thing?\n\n\nI checked with \"git st\" and it reported no changed files. Executing the \"rebase\" once again then \"worked\" as before... I.e. it got stuck in commit 15. The next time it got till commit 16. Then back to commit 15. Etc. Now it is getting stuck on commit 17 (but it doesn't always go up as it did right now).\n\n\n> \n> In cases where COMMIT A succeeded, did it say it did a 3-way merge? Or\n> was it exactly as the output in your original message? i.e. no message\n> at all\n\nIt's always a variation of the same message as shown in my original email. I.e.:\n\nApplying: ...\n...\nApplying: commit XYZ\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nerror: Your local changes to the following files would be overwritten by merge:\n\tsome/file\nPlease, commit your changes or stash them before you can merge.\nAborting\nFailed to merge in the changes.\nPatch failed at 0015 commit XYZ\nThe copy of the patch that failed is found in:\n /path/to/repos/.git/rebase-apply/patch\n\n\n\n\n\nThanks,\nMax"},{"id":"210904","messageId":"513B8037.7060107@gmail.com","threadId":"33097","inReplyTo":"3B5EA38E-9603-4321-AA3C-74354BBC8BFC@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-09T18:32:23Z","receivedAt":"2013-03-09T18:32:23Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 03/09/13 06:26, Max Horn wrote:\n> It tends to fail in separate places, but eventually \"stabilizes\". E.g. I just did a couple test rebases, and it failed twice in commit 14, then the third time in commit 15 (which underlines once more that the failures are inappropriate).\n>\n> The fourth time, something new and weird happened:\n>\n> $ git rebase --abort\n> $ git rebase NEW-PARENT \n> Cannot rebase: You have unstaged changes.\n> Please commit or stash them.\n> $\n>\n> This is quite suspicious. It appears that git for some reason things a file is dirty when it isn't. That could explain the other rebase failures too, couldn't it? But what might cause such a thing?\nYea, that's really suspicious. This could mean there's an issue with\nwhen git is checking the index. Try running these a couple times in a\nclean work tree:\n $ git update-index --refresh\n $ git diff-files\n\nIn a clean work tree, these commands should print nothing. But in your\ncase, these might print random files that git thinks have been modified...\n\nIf the commands do print out some files, check the timestamp from the\ngit index and the filesystem:\n $ git ls-files --debug file1 file2\n $ stat -f \"%N %m %c\" file1 file2\n\nIs this repo on a network drive? Or is it local drive in your Mac?\n"},{"id":"210905","messageId":"513B8468.7070006@gmail.com","threadId":"33097","inReplyTo":"513B8037.7060107@gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-09T18:50:16Z","receivedAt":"2013-03-09T18:50:16Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 03/09/13 13:32, Andrew Wong wrote:\n> Yea, that's really suspicious. This could mean there's an issue with\n> when git is checking the index. Try running these a couple times in a\n> clean work tree:\n> $ git update-index --refresh\n> $ git diff-files\n>\n> In a clean work tree, these commands should print nothing. But in your\n> case, these might print random files that git thinks have been modified...\nBefore you run those commands each time, you probably have to \"touch\"\ncouple files to trigger the issue:\n $ touch file1 file2\n\nMaybe use touch on the files that git rebase has been reporting error?\n"},{"id":"210976","messageId":"C79E1B20-2C42-49FF-A964-285A7049FDED@quendi.de","threadId":"33097","inReplyTo":"513B8037.7060107@gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-10T13:22:58Z","receivedAt":"2013-03-10T13:22:58Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"Sorry for taking so long to reply... :-/\n\nOn 09.03.2013, at 19:32, Andrew Wong wrote:\n\n> On 03/09/13 06:26, Max Horn wrote:\n>> It tends to fail in separate places, but eventually \"stabilizes\". E.g. I just did a couple test rebases, and it failed twice in commit 14, then the third time in commit 15 (which underlines once more that the failures are inappropriate).\n>> \n>> The fourth time, something new and weird happened:\n>> \n>> $ git rebase --abort\n>> $ git rebase NEW-PARENT \n>> Cannot rebase: You have unstaged changes.\n>> Please commit or stash them.\n>> $\n>> \n>> This is quite suspicious. It appears that git for some reason things a file is dirty when it isn't. That could explain the other rebase failures too, couldn't it? But what might cause such a thing?\n> Yea, that's really suspicious. This could mean there's an issue with\n> when git is checking the index. Try running these a couple times in a\n> clean work tree:\n> $ git update-index --refresh\n> $ git diff-files\n> \n> In a clean work tree, these commands should print nothing. But in your\n> case, these might print random files that git thinks have been modified...\n\nI did run\n\n touch lib/*.* src/*.* && git update-index --refresh && git diff-files\n\na couple dozen times (the \"problematic\" files where in src/ and lib), but nothing happened. I just re-checked, and the rebase still fails in the same why...\n\nPerhaps I should add some printfs into the git source to figure out what exactly it thinks is not right about those files... i.e. how does it come to the conclusion that I have local changes, exactly. I don't know how Git does that -- does it take the mtime from (l)stat into account? Perhaps problems with my machine's clock could be responsible?\n\n\n> \n> If the commands do print out some files, check the timestamp from the\n> git index and the filesystem:\n> $ git ls-files --debug file1 file2\n> $ stat -f \"%N %m %c\" file1 file2\n> \n> Is this repo on a network drive? Or is it local drive in your Mac?\n\nLocal (some more details also described in my first email on this thread, but I'll happily provide more data if I can).\n\nThanks again,\nMax"},{"id":"211069","messageId":"CADgNjanQxMFrQG=7SqgAXv5PW8OEfG+1kZt_Mrq27OcP1uyGtA@mail.gmail.com","threadId":"33097","inReplyTo":"C79E1B20-2C42-49FF-A964-285A7049FDED@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-11T19:15:41Z","receivedAt":"2013-03-11T19:15:41Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/10/13, Max Horn wrote:\n> I did run\n>\n> touch lib/*.* src/*.* && git update-index --refresh && git diff-files\n>\n> a couple dozen times (the \"problematic\" files where in src/ and lib), but\n> nothing happened. I just re-checked, and the rebase still fails in the same\n> why...\n>\n> Perhaps I should add some printfs into the git source to figure out what\n> exactly it thinks is not right about those files... i.e. how does it come to\n> the conclusion that I have local changes, exactly. I don't know how Git does\n> that -- does it take the mtime from (l)stat into account? Perhaps problems\n> with my machine's clock could be responsible?\n\nInstead of using \"touch\", maybe it'd be better if you run \"ls-files\"\nand \"stat\" at the point where rebase failed. You should run the\ncommand as soon as rebase failed. Don't try to run any git commands,\nas they might change the index state.\n\nAnd yes, git does make use of mtime and ctime from lstat to some\ndegree when detecting file changes. Inserting printf's to print the\ntimestamp might help, but the output might be too overwhelming to make\nout useful information, especially during a rebase.\n\nBTW, it looks like \"stat\" command on OS X only prints out timestamps\nin seconds, and doesn't show you the nanoseconds part, which may be\nsignificant in your situation. Instead of using the \"stat\" command,\ntry using this python command to print out the nanoseconds parts:\npython -c \"import sys;import os;s=os.stat(sys.argv[1]);print('%d, %f,\n%f' % (s.st_size, s.st_ctime, s.st_mtime))\" file1\n\nPerhaps you could hack git-am.sh a bit to get more debugging info too.\nHm, maybe a good place to start is un-silencing the output of \"git\napply\". Inside \"git-am.sh\", you should see a line like:\n git apply $squelch\nRemove the $squelch, and see what output it generates.\n\nAlso, since you're getting the 3-way merge, you could also insert the\n\"ls-files\" and \"stat\" right after \"git-merge-recursive\", but before\n\"die\".\n"},{"id":"211078","messageId":"E042F4D9-79DF-4AEF-8EDE-41BA9E5FB9EC@quendi.de","threadId":"33097","inReplyTo":"CADgNjanQxMFrQG=7SqgAXv5PW8OEfG+1kZt_Mrq27OcP1uyGtA@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-11T21:10:06Z","receivedAt":"2013-03-11T21:10:06Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 11.03.2013, at 20:15, Andrew Wong wrote:\n\n> On 3/10/13, Max Horn wrote:\n>> I did run\n>> \n>> touch lib/*.* src/*.* && git update-index --refresh && git diff-files\n>> \n>> a couple dozen times (the \"problematic\" files where in src/ and lib), but\n>> nothing happened. I just re-checked, and the rebase still fails in the same\n>> why...\n>> \n>> Perhaps I should add some printfs into the git source to figure out what\n>> exactly it thinks is not right about those files... i.e. how does it come to\n>> the conclusion that I have local changes, exactly. I don't know how Git does\n>> that -- does it take the mtime from (l)stat into account? Perhaps problems\n>> with my machine's clock could be responsible?\n> \n> Instead of using \"touch\", maybe it'd be better if you run \"ls-files\"\n> and \"stat\" at the point where rebase failed. You should run the\n> command as soon as rebase failed. Don't try to run any git commands,\n> as they might change the index state.\n\nSo I tried this:\n\n git rebase branches/stable-4.6 # ... which leads to the error\n git ls-files -m\n\nbut got nothing. Perhaps you had something else in mind, though, but I am not quite sure what... sorry for being dense, but if you let me know what exactly you meant, I'll be happy to try that. As for the stat command:\n\n> \n> And yes, git does make use of mtime and ctime from lstat to some\n> degree when detecting file changes. Inserting printf's to print the\n> timestamp might help, but the output might be too overwhelming to make\n> out useful information, especially during a rebase.\n> \n> BTW, it looks like \"stat\" command on OS X only prints out timestamps\n> in seconds, and doesn't show you the nanoseconds part, which may be\n> significant in your situation. Instead of using the \"stat\" command,\n> try using this python command to print out the nanoseconds parts:\n> python -c \"import sys;import os;s=os.stat(sys.argv[1]);print('%d, %f,\n> %f' % (s.st_size, s.st_ctime, s.st_mtime))\" file1\n\nI can do that, but I am not quite sure what the output should tell me? BTW, I think OS X just does not provide the stat information on a nanosecond level, at least that python command doesn't seem to yield useful extra data... Here is what I got after I just triggered the failing rebase (today it's again a different file it fails on that yesterday...). For comparision, I run stat first on the file with \"conflicts\", and then on a file that is not being touched by the rebase:\n\n File: ‘BAD-FILE’\n Size: 21058 \tBlocks: 48 IO Block: 4096 regular file\nDevice: e000004h/234881028d\tInode: 19108072 Links: 1\nAccess: (0644/-rw-r--r--) Uid: ( 502/ mhorn) Gid: ( 20/ staff)\nAccess: 2013-03-11 21:40:14.000000000 +0100\nModify: 2013-03-11 21:40:12.000000000 +0100\nChange: 2013-03-11 21:40:14.000000000 +0100\n Birth: 2013-03-11 21:40:12.000000000 +0100\n File: ‘NEUTRAL-FILE’\n Size: 1425 \tBlocks: 8 IO Block: 4096 regular file\nDevice: e000004h/234881028d\tInode: 18180450 Links: 1\nAccess: (0644/-rw-r--r--) Uid: ( 502/ mhorn) Gid: ( 20/ staff)\nAccess: 2013-03-11 17:58:30.000000000 +0100\nModify: 2013-03-10 14:20:39.000000000 +0100\nChange: 2013-03-10 14:20:39.000000000 +0100\n Birth: 2013-02-27 16:18:57.000000000 +0100\n\nHere is the output of the python script for the two files:\n21058, 1363034414.000000, 1363034412.000000\n1425, 1362921639.000000, 1362921639.000000\n\n\nOne thing I notice is that ctime equals atime and both are larger than mtime. But I have no clue if that has any significance... hmm\n\n\n\n> Perhaps you could hack git-am.sh a bit to get more debugging info too.\n> Hm, maybe a good place to start is un-silencing the output of \"git\n> apply\". Inside \"git-am.sh\", you should see a line like:\n> git apply $squelch\n> Remove the $squelch, and see what output it generates.\n\n\nerror: BAD-FILE: does not match index\n\nI inserted \"git ls-files -m\" before that but that didn't print anything nor had it any other effect.\n\n> \n> Also, since you're getting the 3-way merge, you could also insert the\n> \"ls-files\" and \"stat\" right after \"git-merge-recursive\", but before\n> \"die\".\n> \n\nAha, so that was interesting: I inserted both a \"stat\" invocation, and also invoked the \"md5\" tool to be able to tell whether the file content matched what I thought it should match. Doing that caused the breaking commit to shift. So, I added a second stat / md5 pair on the new breaking file. After doing that, the rebase suddenly completed! I reset -- hard to the previous state, tried again, and again it worked. And this after consistently failing (albeit in differing places) in maybe a hundred or more tries before. Removing those two calls, it failed again. I tried inserting a \"sleep 1\", just in case it's a race, but with that it still failed.\n\nI then re-added the stat / md5 calls, and -- it failed again, but this much earlier (in commit 8, not around commits 14-18). \n\nSo I added the new conflicting fail to the stat/md5 calls (for a total of three files), and it failed in commit 4. Despite adding the new file (number 4), it got stuck in this very commit in several attempts. I then for a while did some other stuff (like reading through the \"git ls-files\" man page ;-). Trying the rebase once more, with the stat / md5 calls on four files, it went back to failing in the place it started out failing today (commit 16). Adding / remove the stat&md5 invocations didn't seem to have an effect at this point.\n\n\n\nThanks,\nMax"},{"id":"211079","messageId":"E30ECECD-DD58-41E2-AA7C-18F83E5E74E6@quendi.de","threadId":"33097","inReplyTo":"CADgNjanQxMFrQG=7SqgAXv5PW8OEfG+1kZt_Mrq27OcP1uyGtA@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-11T21:20:47Z","receivedAt":"2013-03-11T21:20:47Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"PS: Just as a side note, I should mention that I have done tons of rebases on various repositories on this very machine: same hard drive, same file system; the git version of course has changed over time, but as I already described, I can reproduce the same issue with older git versions.\n\nAll I want to say here is: While this may of course be a bug of OS X or my machine may be faulty or whatever, it is not as if this issue is occurring all over the place. It is so far somehow specific to this repository, or even the particular branch. So it is probably not something as simple as a faulty clock, because then I should be seeing rebases fail all over the place, right? (Hm, OK, admittedly I didn't try any other big rebases in the last couple days. And right now I have no good example at hand, i.e. a non-trivial branch that cleanly rebases to some other branch)\n\n\nCheers,\nMax"},{"id":"211080","messageId":"CADgNjanBm5bj7_jY5WrUXUENr7r6zMxve822OYKcyBpWGZv-SA@mail.gmail.com","threadId":"33097","inReplyTo":"E042F4D9-79DF-4AEF-8EDE-41BA9E5FB9EC@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-11T21:34:01Z","receivedAt":"2013-03-11T21:34:01Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/11/13, Max Horn wrote:\n> So I tried this:\n>\n> git rebase branches/stable-4.6 # ... which leads to the error\n> git ls-files -m\n>\n> but got nothing. Perhaps you had something else in mind, though, but I am\n> not quite sure what... sorry for being dense, but if you let me know what\n> exactly you meant, I'll be happy to try that. As for the stat command:\n\nI'm still digesting the information form the email. Just want to\nquickly mention that the \"ls-files\" command should be:\n $ git ls-files --debug file1 file2\n\nYou should always get output. It prints out stat-like information for\nfiles in the index.\n"},{"id":"211086","messageId":"CADgNja=QJpe2nmqKn9rR1os=zjjqK+dWA+ZLaJA4pgLG8tVgzg@mail.gmail.com","threadId":"33097","inReplyTo":"E30ECECD-DD58-41E2-AA7C-18F83E5E74E6@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-11T22:10:42Z","receivedAt":"2013-03-11T22:10:42Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/11/13, Max Horn wrote:\n> PS: Just as a side note, I should mention that I have done tons of rebases\n> on various repositories on this very machine: same hard drive, same file\n> system; the git version of course has changed over time, but as I already\n> described, I can reproduce the same issue with older git versions.\n\nWhat if you do a \"git clone\" from this repo to an entirely new repo? I\nwonder if the rebase issue still happens in the new repo...\n\nCould you also post the .git/config file from the repo?\n\nIf supported, git could actually make use of threading when doing\n\"stat\"... it should be disabled by default though, but you could try\ndisabling it with this config:\n git config core.preloadindex false\n\nBut I don't know why that'd only affect this one repo and not the\nothers though...\n"},{"id":"211088","messageId":"733410BB-7075-4799-B129-EAD5E64652B3@quendi.de","threadId":"33097","inReplyTo":"CADgNjanBm5bj7_jY5WrUXUENr7r6zMxve822OYKcyBpWGZv-SA@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-11T22:20:33Z","receivedAt":"2013-03-11T22:20:33Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 11.03.2013, at 22:34, Andrew Wong wrote:\n\n> On 3/11/13, Max Horn wrote:\n>> So I tried this:\n>> \n>> git rebase branches/stable-4.6 # ... which leads to the error\n>> git ls-files -m\n>> \n>> but got nothing. Perhaps you had something else in mind, though, but I am\n>> not quite sure what... sorry for being dense, but if you let me know what\n>> exactly you meant, I'll be happy to try that. As for the stat command:\n> \n> I'm still digesting the information form the email. Just want to\n> quickly mention that the \"ls-files\" command should be:\n> $ git ls-files --debug file1 file2\n> \n> You should always get output. It prints out stat-like information for\n> files in the index.\n\nAha, I see. I inserted that into git-am, once right before git-merge-recursive and once right after it (just before a call to rerere).\n\n\nThis is what I got;\n\n\nApplying: COMMIT X\nerror: BAD-FILE: does not match index\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nGOOD-FILE\n ctime: 1362921639:0\n mtime: 1362921639:0\n dev: 234881028\tino: 18665879\n uid: 502\tgid: 20\n size: 25429\tflags: 0\nBAD-FILE\n ctime: 1363040264:0\n mtime: 1363040264:0\n dev: 234881028\tino: 19170773\n uid: 502\tgid: 20\n size: 52906\tflags: 0\nerror: Your local changes to the following files would be overwritten by merge:\n\tBAD-FILE\nPlease, commit your changes or stash them before you can merge.\nAborting\nGOOD-FILE\n ctime: 1362921639:0\n mtime: 1362921639:0\n dev: 234881028\tino: 18665879\n uid: 502\tgid: 20\n size: 25429\tflags: 0\nBAD-FILE\n ctime: 1363040264:0\n mtime: 1363040264:0\n dev: 234881028\tino: 19170773\n uid: 502\tgid: 20\n size: 52906\tflags: 0\nFailed to merge in the changes.\nPatch failed at 0015 COMMIT X\n...\n\nSo the ctime/mtine for the BAD-FILE do not differ.\nAfter this, I also run \"ls-files\" on the command line, and got:\n\nGOOD-FILE gd\n ctime: 1362921639:0\n mtime: 1362921639:0\n dev: 234881028\tino: 18665879\n uid: 502\tgid: 20\n size: 25429\tflags: 0\nBAD-FILE\n ctime: 1363040266:0\n mtime: 1363040264:0\n dev: 234881028\tino: 19170773\n uid: 502\tgid: 20\n size: 52906\tflags: 0\n\nSo now the ctime of the bad file is more recent than the mtime.\n\n\nMax"},{"id":"211090","messageId":"ED1442D4-C011-49F3-928C-0BE0280F7D42@quendi.de","threadId":"33097","inReplyTo":"CADgNja=QJpe2nmqKn9rR1os=zjjqK+dWA+ZLaJA4pgLG8tVgzg@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-11T22:36:09Z","receivedAt":"2013-03-11T22:36:09Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 11.03.2013, at 23:10, Andrew Wong wrote:\n\n> On 3/11/13, Max Horn wrote:\n>> PS: Just as a side note, I should mention that I have done tons of rebases\n>> on various repositories on this very machine: same hard drive, same file\n>> system; the git version of course has changed over time, but as I already\n>> described, I can reproduce the same issue with older git versions.\n> \n> What if you do a \"git clone\" from this repo to an entirely new repo? I\n> wonder if the rebase issue still happens in the new repo...\n\nThe problem seems to be non-existent in a clone. \n\n> \n> Could you also post the .git/config file from the repo?\n\n[core]\n\trepositoryformatversion = 0\n\tfilemode = true\n\tbare = false\n\tlogallrefupdates = true\n\tignorecase = true\n\tprecomposeunicode = false\n\nOther than that, it just contains some a [remote] section and several [branch] sections. None of these contains any fancy (i.e. the branch sections just say \"remote = origin\" and give the name of the remote branch).\n\nLooking at the git config man page to check what each of my config settings does, I discovered \"trustctime\". And adding\n\ttrustctime = false\nto .git/config made the rebase work, every single time. Huh. \n\n\nAdding this to the fact that a clone works fine, I wonder if something *is* touching my files, but just in that directory. But what could it be? One nagging suspicion is the \"file versioning\" feature Apple introduced as part of Time Machine in OS X 10.7; it's kind of a \"version control system for n00bs\" for arbitrary documents. It has caused me some pain in the past.\n\nBut I just re-checked, and problematic repos is explicitly on the Time Machine exclusion list. I also used the \"tmutil isexcluded FILES\" to verify that the problematic files are really on the TM exclusion list. Finally, I moved the one of the repos subdirectory containing most of the problematic files, and then run \"git checkout\". In other instances, this sufficed to \"disassociate\" a file from an unwanted TM version history. But doing that had no effect here, i.e. also with the freshly regenerated files, the problems appear.\n\n> \n> If supported, git could actually make use of threading when doing\n> \"stat\"... it should be disabled by default though, but you could try\n> disabling it with this config:\n> git config core.preloadindex false\n> \n> But I don't know why that'd only affect this one repo and not the\n> others though...\n> \nThis setting doesn't seem to have any effect on the issue at hand.\n\n\nCheers,\nMax"},{"id":"211092","messageId":"CADgNja=oyAVVNTAY-OG5U2gmoYGdpUGDVKvDb4EdD2Q+9KgDcw@mail.gmail.com","threadId":"33097","inReplyTo":"ED1442D4-C011-49F3-928C-0BE0280F7D42@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-11T22:54:15Z","receivedAt":"2013-03-11T22:54:15Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/11/13, Max Horn wrote:\n> Looking at the git config man page to check what each of my config settings\n> does, I discovered \"trustctime\". And adding\n> \ttrustctime = false\n> to .git/config made the rebase work, every single time. Huh.\n>\n>\n> Adding this to the fact that a clone works fine, I wonder if something *is*\n> touching my files, but just in that directory. But what could it be? One\n> nagging suspicion is the \"file versioning\" feature Apple introduced as part\n> of Time Machine in OS X 10.7; it's kind of a \"version control system for\n> n00bs\" for arbitrary documents. It has caused me some pain in the past.\n>\n> But I just re-checked, and problematic repos is explicitly on the Time\n> Machine exclusion list. I also used the \"tmutil isexcluded FILES\" to verify\n> that the problematic files are really on the TM exclusion list. Finally, I\n> moved the one of the repos subdirectory containing most of the problematic\n> files, and then run \"git checkout\". In other instances, this sufficed to\n> \"disassociate\" a file from an unwanted TM version history. But doing that\n> had no effect here, i.e. also with the freshly regenerated files, the\n> problems appear.\n\nWould you be able to turn off Time Machine completely and do a few\ntests? If it does works, then it becomes a matter of fixing Time\nMachine...\n"},{"id":"211093","messageId":"C53F5B74-C634-461A-B9AA-B6B5A4310B43@quendi.de","threadId":"33097","inReplyTo":"CADgNja=oyAVVNTAY-OG5U2gmoYGdpUGDVKvDb4EdD2Q+9KgDcw@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-12T00:15:56Z","receivedAt":"2013-03-12T00:15:56Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 11.03.2013, at 23:54, Andrew Wong wrote:\n\n> On 3/11/13, Max Horn wrote:\n>> Looking at the git config man page to check what each of my config settings\n>> does, I discovered \"trustctime\". And adding\n>> \ttrustctime = false\n>> to .git/config made the rebase work, every single time. Huh.\n>> \n>> \n>> Adding this to the fact that a clone works fine, I wonder if something *is*\n>> touching my files, but just in that directory. But what could it be? One\n>> nagging suspicion is the \"file versioning\" feature Apple introduced as part\n>> of Time Machine in OS X 10.7; it's kind of a \"version control system for\n>> n00bs\" for arbitrary documents. It has caused me some pain in the past.\n>> \n>> But I just re-checked, and problematic repos is explicitly on the Time\n>> Machine exclusion list. I also used the \"tmutil isexcluded FILES\" to verify\n>> that the problematic files are really on the TM exclusion list. Finally, I\n>> moved the one of the repos subdirectory containing most of the problematic\n>> files, and then run \"git checkout\". In other instances, this sufficed to\n>> \"disassociate\" a file from an unwanted TM version history. But doing that\n>> had no effect here, i.e. also with the freshly regenerated files, the\n>> problems appear.\n> \n> Would you be able to turn off Time Machine completely and do a few\n> tests? If it does works, then it becomes a matter of fixing Time\n> Machine...\n\nI did turn it off just now, but no effect. Then again, daemons like revisiond were still running...\n\n\nOne more thing: I used the \"fs_usage\" to monitor what process accessed what file during one of those failing \"git rebase\" runs. I then searched through this to determine which processes accessed the \"bad\" file in this time. The result where these processes (aggregated):\n\n git\n revisiond\n fseventsd\n git-merge-recursive\n\nNote that Time Machine was not running, but revisiond is... from its manpage:\n\n revisiond is the daemon that manages document revisions created by applications and system services.\n\n There are no configurations to revisiond, and users should not run revisiond manually.\n\nThis is the process I am suspecting. Specifically, a fchflags call it makes (see that attached excerpt of the fs_usage output). I am not sure, but my guess would be that it sets SF_ARCHIVED on the file. Causing its ctime to wander... Yuck.\n\nBut I don't know how to control it... and I am not sure if I can just kill it. Hrm. I'll try to dig some more into it, perhaps I can somehow confirm that this is *really* the cause of the problems, and somehow prevent it.\n\n\nCheers,\nMax\n\n\n\n00:59:54.349156 lstat64 src/BAD_FILE 0.000050 git.623953\n00:59:54.349160 open F=5 (R_____) src/BAD_FILE 0.000004 git.623953\n00:59:54.350659 close F=5 0.000007 git.623953\n00:59:54.371716 lstat64 src/BAD_FILE 0.000002 git.623955\n00:59:54.429674 lstat64 src/BAD_FILE 0.000002 git.623959\n00:59:54.600060 lstat64 src/BAD_FILE 0.000007 git.623959\n00:59:54.600151 stat64 /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000006 revisiond.623963\n00:59:54.600154 stat64 /Users/mhorn/the-path-to-my-repository/src 0.000003 revisiond.623963\n00:59:54.600160 open F=7 (R_____) /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000006 revisiond.623963\n00:59:54.600161 fstatfs64 F=7 0.000002 revisiond.623963\n00:59:54.600163 close F=7 0.000002 revisiond.623963\n00:59:54.600387 unlink src/BAD_FILE 0.000328 W git.623959\n00:59:54.600429 open F=5 (_WC__E) src/BAD_FILE 0.000039 git.623959\n00:59:54.602910 write F=5 B=0x4000 0.000040 git.623959\n00:59:54.602932 write F=5 B=0x4000 0.000017 git.623959\n00:59:54.602947 write F=5 B=0x4000 0.000011 git.623959\n00:59:54.602958 write F=5 B=0x4000 0.000009 git.623959\n00:59:54.602969 write F=5 B=0x4000 0.000009 git.623959\n00:59:54.602977 write F=5 B=0x12f5 0.000007 git.623959\n00:59:54.602983 fstat64 F=5 0.000004 git.623959\n00:59:54.603032 close F=5 0.000049 git.623959\n00:59:54.621731 lstat64 /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004 fseventsd.1664\n00:59:54.882870 lstat64 src/BAD_FILE 0.000002 git.623993\n00:59:54.882872 open F=5 (R_____) src/BAD_FILE 0.000003 git.623993\n00:59:54.883042 close F=5 0.000002 git.623993\n00:59:55.021956 lstat64 src/BAD_FILE 0.000003 git.624027\n00:59:55.021959 open F=4 (R_____) src/BAD_FILE 0.000003 git.624027\n00:59:55.022138 close F=4 0.000003 git.624027\n00:59:56.600440 open F=7 (R_____) /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000014 revisiond.623963\n00:59:56.600442 fcntl F=7 0.000002 revisiond.623963\n00:59:56.600445 close F=7 0.000004 revisiond.623963\n00:59:56.600449 stat64 /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004 revisiond.623963\n00:59:56.600452 stat64 /Users/mhorn/the-path-to-my-repository/src 0.000003 revisiond.623963\n00:59:56.600455 open F=7 (R_____) /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004 revisiond.623963\n00:59:56.600457 fstatfs64 F=7 0.000002 revisiond.623963\n00:59:56.600459 close F=7 0.000002 revisiond.623963\n00:59:56.600687 open F=7 (R_____) /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000006 revisiond.623963\n00:59:56.600688 fstat64 F=7 0.000002 revisiond.623963\n00:59:56.600698 fchflags F=7 [garbled output removed] 0.000010 revisiond.623963\n00:59:56.600701 close F=7 0.000003 revisiond.623963\n00:59:56.624161 lstat64 /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004 fseventsd.1664\n00:59:56.981172 lstat64 src/BAD_FILE 0.000004 git.624517\n00:59:57.015622 lstat64 src/BAD_FILE 0.000005 git.624527\n00:59:57.118844 lstat64 src/BAD_FILE 0.000005 git-merge-recurs.624544\n01:00:00.194634 lstat64 src/BAD_FILE 0.000002 git.624580\n01:00:00.194637 open F=5 (R_____) src/BAD_FILE 0.000003 git.624580\n01:00:00.194815 close F=5 0.000003 git.624580\n"},{"id":"211094","messageId":"A3AD5861-FE88-4D6E-B10A-B83F68BA6368@quendi.de","threadId":"33097","inReplyTo":"CADgNja=oyAVVNTAY-OG5U2gmoYGdpUGDVKvDb4EdD2Q+9KgDcw@mail.gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Max Horn","fromEmail":"max@quendi.de","sentAt":"2013-03-12T00:29:45Z","receivedAt":"2013-03-12T00:29:45Z","isPatch":false,"sender":{"key":"max@quendi.de","avatar":"https://avatars.githubusercontent.com/u/241512?v=4"},"body":"\nOn 11.03.2013, at 23:54, Andrew Wong wrote:\n\n> On 3/11/13, Max Horn wrote:\n>> Looking at the git config man page to check what each of my config settings\n>> does, I discovered \"trustctime\". And adding\n>> \ttrustctime = false\n>> to .git/config made the rebase work, every single time. Huh.\n>> \n>> \n>> Adding this to the fact that a clone works fine, I wonder if something *is*\n>> touching my files, but just in that directory. But what could it be? One\n>> nagging suspicion is the \"file versioning\" feature Apple introduced as part\n>> of Time Machine in OS X 10.7; it's kind of a \"version control system for\n>> n00bs\" for arbitrary documents. It has caused me some pain in the past.\n>> \n>> But I just re-checked, and problematic repos is explicitly on the Time\n>> Machine exclusion list. I also used the \"tmutil isexcluded FILES\" to verify\n>> that the problematic files are really on the TM exclusion list. Finally, I\n>> moved the one of the repos subdirectory containing most of the problematic\n>> files, and then run \"git checkout\". In other instances, this sufficed to\n>> \"disassociate\" a file from an unwanted TM version history. But doing that\n>> had no effect here, i.e. also with the freshly regenerated files, the\n>> problems appear.\n> \n> Would you be able to turn off Time Machine completely and do a few\n> tests? If it does works, then it becomes a matter of fixing Time\n> Machine...\n> \n\nsudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist\n\n-> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs.\n\nSo it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly).\n\nAndrew, thank you very much for your persistent guidance and help. I definitely owe you a beverage-of-your-choice ;-).\n\nCheers,\nMax"},{"id":"211095","messageId":"CAEBDL5V2ZWPQUDJU-tDJe8hsOJVf9+4Bx4WxEB6fhm+ZRCq9kg@mail.gmail.com","threadId":"33097","inReplyTo":"A3AD5861-FE88-4D6E-B10A-B83F68BA6368@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-03-12T00:41:03Z","receivedAt":"2013-03-12T00:41:03Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Mon, Mar 11, 2013 at 8:29 PM, Max Horn wrote:\n[snip]\n>\n> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist\n>\n> -> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs.\n>\n> So it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly).\n\nI just wanted to say thank you for spamming the list with this. I've\nnot upgraded to a new Mac OS X yet, but now I know I need to watch out\nfor this issue. I'm glad you were able to get to the bottom of it,\nand I'd love to hear if you find a reasonable solution.\n\n-John\n"},{"id":"211098","messageId":"513E7DAD.4030201@gmail.com","threadId":"33097","inReplyTo":"A3AD5861-FE88-4D6E-B10A-B83F68BA6368@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-12T00:58:21Z","receivedAt":"2013-03-12T00:58:21Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 03/11/13 20:29, Max Horn wrote:\n> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist\n>\n> -> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs.\n>\n> So it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly).\n>\n> Andrew, thank you very much for your persistent guidance and help. I definitely owe you a beverage-of-your-choice ;-).\nAwesome! I was starting to worry that we'd never figure out what the\nissue is. Good thing you know your way around OS X and its debugging\ntools. :)\n\nMaybe drop an email if you figure out what's causing revisiond to be so\npersistent about those specific files. Might help any who run into\nsimilar issues in the future.\n\nCheers!\n"},{"id":"211097","messageId":"20130312010114.GA21026@sigill.intra.peff.net","threadId":"33097","inReplyTo":"A3AD5861-FE88-4D6E-B10A-B83F68BA6368@quendi.de","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-12T01:01:14Z","receivedAt":"2013-03-12T01:01:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 12, 2013 at 01:29:45AM +0100, Max Horn wrote:\n\n> So it seems pretty clear what the cause of this is. Now I still need\n> to figure out why it affects that particular repository and not\n> others. But at this point I guess it is safe to say that Apple's\n> auto-crap-magic revisiond is the root of the problem, and git is\n> purely a victim. So I'll stop spamming this list with this issue for\n> now, and see if I can figure out a fix that is less invasive than\n> turning off revisiond completely (which some application rely on, so\n> disabling it may break them badly).\n\n>From \"git help config\":\n\n core.trustctime\n If false, the ctime differences between the index and the working\n tree are ignored; useful when the inode change time is regularly\n modified by something outside Git (file system crawlers and some\n backup systems). See git-update- index(1). True by default.\n\n-Peff\n"},{"id":"211099","messageId":"513E7EEE.3060107@gmail.com","threadId":"33097","inReplyTo":"20130312010114.GA21026@sigill.intra.peff.net","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-12T01:03:42Z","receivedAt":"2013-03-12T01:03:42Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 03/11/13 21:01, Jeff King wrote:\n> From \"git help config\":\n>\n> core.trustctime\n> If false, the ctime differences between the index and the working\n> tree are ignored; useful when the inode change time is regularly\n> modified by something outside Git (file system crawlers and some\n> backup systems). See git-update- index(1). True by default.\nIn an earlier email, Max did mention setting the config does workaround\nthe issue. But it's still strange that it only happens to a few specific\nfiles in this particular repo. The issue never popped up in other repos\nthat he has, which I assume has all been excluded from Time Machine...\n"},{"id":"211100","messageId":"20130312011004.GA21242@sigill.intra.peff.net","threadId":"33097","inReplyTo":"513E7EEE.3060107@gmail.com","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-12T01:10:04Z","receivedAt":"2013-03-12T01:10:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote:\n\n> On 03/11/13 21:01, Jeff King wrote:\n> > From \"git help config\":\n> >\n> > core.trustctime\n> > If false, the ctime differences between the index and the working\n> > tree are ignored; useful when the inode change time is regularly\n> > modified by something outside Git (file system crawlers and some\n> > backup systems). See git-update- index(1). True by default.\n>\n> In an earlier email, Max did mention setting the config does workaround\n> the issue. But it's still strange that it only happens to a few specific\n> files in this particular repo. The issue never popped up in other repos\n> that he has, which I assume has all been excluded from Time Machine...\n\nAh, sorry, I missed the earlier reference to it. trustctime is the only\nsensible thing to do from the git side. I think figuring out the rest is\ndeep Apple magic that I'm not qualified to comment on.\n\n-Peff\n"},{"id":"211104","messageId":"20130312082650.GA4075@sandbox-ub.fritz.box","threadId":"33097","inReplyTo":"20130312011004.GA21242@sigill.intra.peff.net","subject":"Re: rebase: strange failures to apply patc 3-way","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2013-03-12T08:26:51Z","receivedAt":"2013-03-12T08:26:51Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Mar 11, 2013 at 09:10:04PM -0400, Jeff King wrote:\n> On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote:\n> \n> > On 03/11/13 21:01, Jeff King wrote:\n> > > From \"git help config\":\n> > >\n> > > core.trustctime\n> > > If false, the ctime differences between the index and the working\n> > > tree are ignored; useful when the inode change time is regularly\n> > > modified by something outside Git (file system crawlers and some\n> > > backup systems). See git-update- index(1). True by default.\n> >\n> > In an earlier email, Max did mention setting the config does workaround\n> > the issue. But it's still strange that it only happens to a few specific\n> > files in this particular repo. The issue never popped up in other repos\n> > that he has, which I assume has all been excluded from Time Machine...\n> \n> Ah, sorry, I missed the earlier reference to it. trustctime is the only\n> sensible thing to do from the git side. I think figuring out the rest is\n> deep Apple magic that I'm not qualified to comment on.\n\n>From what I read isn't the ctime the only thing that changes? I read\nthat you tried this option and the issues disappeared? Maybe the\nresolution (or part of it) is to change the default of core.trustctime\nto false on osx?\n\nCheers Heiko\n"}]}