On Fri, Jun 15, 2012 at 9:08 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. This caught my attention because my team and I have had a very similar experience. We're iOS devs using Xcode and we use pull --rebase a lot. About 1 in 10 times we get these mysterious conflicts that don't appear in git status. Aborting the rebase and starting over usually fixes the problem, but much anxiety was caused by people who took the advice to run git rebase --skip and found that their commits were missing and thought they'd lost work. I had to introduce everyone to git reflog a lot sooner than I'd hoped to. I've had the intention of asking about this problem on the list for quite a while now but the sporadic nature of the thing made it hard to put together a coherent bug report. > 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? If Xcode is doing anything it is probably that. It certainly doesn't change the content of files spontaneously. > 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). If you're not careful that can happen. Xcode will offer to re-save files that vanish. But I've seen mystery conflicts many many times and this was not the cause. >> > 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. Interesting. Maybe this will help get to the bottom of the problem. Thanks! -n8 -- HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch http://hexalex.com On The App Store: http://bit.ly/8Mj1CU On Facebook: http://bit.ly/9MIJiV On Twitter: http://twitter.com/hexalexgame http://n8gray.org -- 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