General and development mailing list for Git, a distributed version control system

Eric Gillum | 15 Jun 2012 01:41

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

Hi,

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. I can't skip because the commits only exist on B.
So I abort and just try the rebase from scratch, and somewhat less than half the time git claims there are
conflicts in certain files. Sometimes I bite the bullet and go fix those conflicts. Sometimes I abort
again and rebase again until eventually...it just suc
ceeds!

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

This is git version 1.7.9.3. Your insight appreciated.--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

headers

Eric Gillum | 15 Jun 2012 01:49

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

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.

On Jun 14, 2012, at 4:41 PM, Eric Gillum wrote:

> Hi,
> 
> 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. I can't skip because the commits only exist on B.
So I abort and just try the rebase from scratch, and somewhat less than half the time git claims there are
conflicts in certain files. Sometimes I bite the bullet and go fix those conflicts. Sometimes I abort
again and rebase again until eventually...it just s
 ucceeds!
> 
> 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"?
> 
> This is git version 1.7.9.3. Your insight appreciated.

headers

Jeff King | 15 Jun 2012 18:08

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

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.

(Continue reading)

headers

Nathan Gray | 16 Jun 2012 20:39

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

On Fri, Jun 15, 2012 at 9:08 AM, Jeff King <peff <at> peff.net> 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.

(Continue reading)

headers

Eric Gillum | 21 Jun 2012 23:11

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

Hi,

It finally happened again today. I avoided git status and instead ran git diff-files, which showed a mix of
files that had been edited today (only on the branch) and files that had been edited days ago (only on the
branch). This particular rebase claimed that the files that had been edited days ago were the ones that had
local changes. I don't know enough about the rebase/merge procedure to say anything. I include the output
below, substituting commit messages and file names.

I've tried it with and without my editors open (including Xcode). It seems more or less "stuck" -- unable to
complete the rebase -- but both the files reported as having local changes and the files reported by git
diff-files are different every time (albeit always files that were edited on the branch).

> git rebase master
First, rewinding head to replay your work on top of it...
Applying: <commit1 msg>
Applying: <commit2 msg>
Applying: <commit3 msg>
Applying: <commit4 msg>
Applying: <commit5 msg>
Using index info to reconstruct a base tree...
<stdin>:124: trailing whitespace.
<stdin>:125: trailing whitespace.
<stdin>:218: trailing whitespace.
<stdin>:278: trailing whitespace.
<stdin>:310: trailing whitespace.
warning: squelched 4 whitespace errors
warning: 9 lines add whitespace errors.
Falling back to patching base and 3-way merge...
error: Your local changes to the following files would be overwritten by merge:
	<file1>

(Continue reading)

headers

Eric Gillum | 29 Jun 2012 19:55

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

At wit's end, I just tried the solution at http://stackoverflow.com/questions/5074136, which is "git
config --global core.trustctime false" and it worked immediately on a rebase I've been trying to do for
the last 20 minutes. Jeff hinted earlier in this thread that this could be because Xcode is touching file
metadata. 

I'd be grateful if anyone can explain the implications of running this config (am I screwing myself in some
other way down the road?). The only thing I can find makes it seem fairly harmless. Here's the excerpt from git-update-index:

"The command also looks at core.trustctime configuration variable. It can be useful when the inode change
time is regularly modified by something outside Git (file system crawlers and backup systems use ctime
for marking files processed) (see git-config(1))."

On Jun 21, 2012, at 2:11 PM, Eric Gillum wrote:

> Hi,
> 
> It finally happened again today. I avoided git status and instead ran git diff-files, which showed a mix of
files that had been edited today (only on the branch) and files that had been edited days ago (only on the
branch). This particular rebase claimed that the files that had been edited days ago were the ones that had
local changes. I don't know enough about the rebase/merge procedure to say anything. I include the output
below, substituting commit messages and file names.
> 
> I've tried it with and without my editors open (including Xcode). It seems more or less "stuck" -- unable to
complete the rebase -- but both the files reported as having local changes and the files reported by git
diff-files are different every time (albeit always files that were edited on the branch).
> 
>> git rebase master
> First, rewinding head to replay your work on top of it...
> Applying: <commit1 msg>
> Applying: <commit2 msg>

(Continue reading)