On 08.03.2013, at 20:20, Andrew Wong wrote:
> On 3/8/13, Max Horn <m...@quendi.de> 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
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: 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:
Please, commit your changes or stash them before you can merge.
Failed to merge in the changes.
Patch failed at 0015 commit XYZ
The copy of the patch that failed is found in:
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