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
>> 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
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).
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