On 08.03.2013, at 20:20, Andrew Wong wrote: > On 3/8/13, Max Horn <max@xxxxxxxxx> wrote: >> Same result, it works fine. > > Just shooting in the dark here... I wonder if there's some background > process running in OS X that's messing with the files/directories > while rebase is working... backup, virus scan, etc? Or maybe some > programs that you're using at the same time? Maybe also make sure you > don't have any programs (shells, editors, etc.) opened that's > accessing those files/directories? I 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. No diference. In the end I even did a reboot, but that made no differences either (which I am quite relieved about, I must say ;-). > > Does the error always happen at COMMIT A and COMMIT B? Or is it all > over the place? 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? I 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). > > In cases where COMMIT A succeeded, did it say it did a 3-way merge? Or > was it exactly as the output in your original message? i.e. no message > at all It's always a variation of the same message as shown in my original email. I.e.: Applying: ... ... Applying: commit XYZ 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/file Please, commit your changes or stash them before you can merge. Aborting Failed to merge in the changes. Patch failed at 0015 commit XYZ The copy of the patch that failed is found in: /path/to/repos/.git/rebase-apply/patch Thanks, 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