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