Re: rebase: strange failures to apply patc 3-way

From: Max Horn <max@quendi.de>
Date: Mar 10, 2013, 13:22 UTC
Message-ID: <C79E1B20-2C42-49FF-A964-285A7049FDED@quendi.de>
In-Reply-To: <513B8037.7060107@gmail.com>

Sorry for taking so long to reply... :-/

On 09.03.2013, at 19:32, Andrew Wong wrote:

Show 20 quoted lines

> 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?

Show 7 quoted lines

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