Re: git rebase keeps saying local changes would conflict..what changes?

From: Nathan Gray <n8gray@n8gray.org>
Date: Jun 16, 2012, 18:39 UTC
Message-ID: <CA+7g9JxbkD+b4dzAiWdkdyGuQm72jj=GSybZmB-Tr5iGcL-4eA@mail.gmail.com>
In-Reply-To: <20120615160813.GB4572@sigill.intra.peff.net>

On Fri, Jun 15, 2012 at 9:08 AM, Jeff King <peff@peff.net> wrote:

Show 6 quoted lines

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

Show 7 quoted lines

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

Show 6 quoted lines

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

Show 15 quoted lines

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