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 majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
