Sorry for taking so long to reply... :-/ On 09.03.2013, at 19:32, Andrew Wong wrote: > On 03/09/13 06:26, Max Horn wrote: >> 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). >> >> The fourth time, something new and weird happened: >> >> $ git rebase --abort >> $ git rebase NEW-PARENT >> Cannot rebase: You have unstaged changes. >> Please commit or stash them. >> $ >> >> 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? > Yea, that's really suspicious. This could mean there's an issue with > when git is checking the index. Try running these a couple times in a > clean work tree: > $ git update-index --refresh > $ git diff-files > > In a clean work tree, these commands should print nothing. But in your > case, these might print random files that git thinks have been modified... I did run touch lib/*.* src/*.* && git update-index --refresh && git diff-files a 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... Perhaps 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? > > If the commands do print out some files, check the timestamp from the > git index and the filesystem: > $ git ls-files --debug file1 file2 > $ stat -f "%N %m %c" file1 file2 > > Is this repo on a network drive? Or is it local drive in your Mac? Local (some more details also described in my first email on this thread, but I'll happily provide more data if I can). Thanks again, 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