On Thu, Jun 14, 2012 at 04:49:54PM -0700, Eric Gillum wrote: > Just found a similar problem here: > http://stackoverflow.com/questions/5074136. I do use Xcode, which may > be related. Maybe I'll try the proposed solution. But I'd still love > to know what the issue is, or how I can help debug it. Reading that thread, one answer mentions that Xcode may overwrite files in the middle of your rebase. There is no git fix for that; tweaking files in the middle of a git operation can only lead to bad and confusing results. Turning off trustctime only makes sense if Xcode is touching the file metadata but not modifying the file at all. Is that what's happening? Further confusing to me is that the original poster there mentioned that the dirty state is untracked files in the working directory. But ctime shouldn't be involved at all, then. It sounds more like tracked files were not deleted when we switched away from the branch (either because of a bug in git, or because something like Xcode is re-creating them behind our back). > > I have a sometimes-reproducible issue when trying to rebase. In > > short, I've created a local branch B off of master, made several > > commits on B, switched to master and pulled, switched back to B, > > then tried "git rebase master", which fails. What I get about half > > the time is a failure that claims I have local changes to files that > > would be overridden by the merge. Nothing is reported by git status > > (I've even tried closing all editors), so I am forced to do git > > rebase --abort or --skip. Try running "git diff-files" instead of "git status". If something is munging the files behind git's back, then the index (which should have been refreshed by "git update-index --refresh" at the start of the rebase) will be out of date. "git status" will refresh the index itself, but we would not want that if we are interested in making the same comparison that the rebase is doing. > > What's wrong? Why would I get the local changes warning but have no > > local changes? The merge conflicts tend to be within a file that has > > been changed multiple times on B. These "conflicts" are literally > > changes I've made at one point or another on B. The relevant files > > were never touched on master while I was working on B. And no > > changes on B are amends or reverts or anything remotely tricky -- > > they're simply more changes committed with "git commit". So why > > would I have to "resolve conflicts"? You shouldn't have to if there were no changes to the same areas on master. But if something like Xcode were externally munging files to some other version, then it would make sense. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html