A follow up: I 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. All 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. And: is this a known issue, I wonder? Cheers, Max On 07.03.2013, at 11:16, Max Horn wrote: > 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. > > 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 <https://github.com/buchuki/gitifyhg>. > > 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). > > Specifically, I wanted to rebase a branch with some experimental commits. The strange things started with this: > > $ git rebase MY-NEW-BASE > First, rewinding head to replay your work on top of it... > Applying: SOME COMMIT > Applying: SOME OTHER COMMIT > ... > Applying: COMMIT A > Applying: COMMIT B > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > error: Your local changes to the following files would be overwritten by merge: > some/source.file > Please, commit your changes or stash them before you can merge. > Aborting > Failed to merge in the changes. > Patch failed at 0014 COMMIT B > The copy of the patch that failed is found in: > /path/to/my/repo/.git/rebase-apply/patch > > When you have resolved this problem, run "git rebase --continue". > If you prefer to skip this patch, run "git rebase --skip" instead. > To check out the original branch and stop rebasing, run "git rebase --abort". > > > Now, what is strange about this is that the failed patch actually applies cleanly: > > $ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch > patching file some/source.file > $ > > 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! > > 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): > > $ git rebase --abort > $ git rebase MY-NEW-BASE > First, rewinding head to replay your work on top of it... > Applying: SOME COMMIT > Applying: SOME OTHER COMMIT > ... > Applying: COMMIT A > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > error: Your local changes to the following files would be overwritten by merge: > some/othersource.file > some/yetanother.file > Please, commit your changes or stash them before you can merge. > Aborting > Failed to merge in the changes. > Patch failed at 0013 COMMIT A > The copy of the patch that failed is found in: > /path/to/my/repo/.git/rebase-apply/patch > > When you have resolved this problem, run "git rebase --continue". > If you prefer to skip this patch, run "git rebase --skip" instead. > To check out the original branch and stop rebasing, run "git rebase --abort". > > > > 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: > > > $ git rebase --abort > $ git rebase MY-NEW-BASE > First, rewinding head to replay your work on top of it... > Applying: SOME COMMIT > Applying: SOME OTHER COMMIT > ... > Applying: COMMIT A > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > error: Your local changes to the following files would be overwritten by merge: > some/othersource.file > Please, commit your changes or stash them before you can merge. > Aborting > Failed to merge in the changes. > Patch failed at 0013 COMMIT A > The copy of the patch that failed is found in: > /path/to/my/repo/.git/rebase-apply/patch > > When you have resolved this problem, run "git rebase --continue". > If you prefer to skip this patch, run "git rebase --skip" instead. > To check out the original branch and stop rebasing, run "git rebase --abort". > > > Again it fails in commit A -- but this time, it only thinks one file is problematic. HUH? Again, the patch actually applies cleanly: > > $ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch > patching file some/othersource.file > patching file some/yetanother.file > > > 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). > > > 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? > > > Cheers, > Max > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html