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 

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,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to