# git rebase keeps saying local changes would conflict..what changes? 6 messages from 2012-06-14 to 2012-06-29. Participants: Eric Gillum, Jeff King, Nathan Gray. Thread: https://gitlist.dev/t/30813 ## Eric Gillum, 2012-06-14 23:41 Subject: git rebase keeps saying local changes would conflict..what changes? Message-ID: URL: https://gitlist.dev/e/D8381FF2-A6B4-4596-B565-7E5BB3F239D8%40color.com ``` 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. ``` ## Eric Gillum, 2012-06-14 23:49 Subject: Re: git rebase keeps saying local changes would conflict..what changes? Message-ID: <2652085F-C1BC-4EAB-9289-F508E64982F0@color.com> URL: https://gitlist.dev/e/2652085F-C1BC-4EAB-9289-F508E64982F0%40color.com In-Reply-To: ``` 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. ``` ## Jeff King, 2012-06-15 16:08 Subject: Re: git rebase keeps saying local changes would conflict..what changes? Message-ID: <20120615160813.GB4572@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120615160813.GB4572%40sigill.intra.peff.net In-Reply-To: <2652085F-C1BC-4EAB-9289-F508E64982F0@color.com> ``` 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 ``` ## Nathan Gray, 2012-06-16 18:39 Subject: Re: git rebase keeps saying local changes would conflict..what changes? Message-ID: URL: https://gitlist.dev/e/CA%2B7g9JxbkD%2Bb4dzAiWdkdyGuQm72jj%3DGSybZmB-Tr5iGcL-4eA%40mail.gmail.com In-Reply-To: <20120615160813.GB4572@sigill.intra.peff.net> ``` On Fri, Jun 15, 2012 at 9:08 AM, Jeff King 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 ``` ## Eric Gillum, 2012-06-21 21:11 Subject: Re: git rebase keeps saying local changes would conflict..what changes? Message-ID: <890895A7-9DB5-4FD5-A45B-03151236FD70@color.com> URL: https://gitlist.dev/e/890895A7-9DB5-4FD5-A45B-03151236FD70%40color.com In-Reply-To: <20120615160813.GB4572@sigill.intra.peff.net> ``` 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: Applying: Applying: Applying: Applying: Using index info to reconstruct a base tree... :124: trailing whitespace. :125: trailing whitespace. :218: trailing whitespace. :278: trailing whitespace. :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: Please, commit your changes or stash them before you can merge. Aborting Failed to merge in the changes. Patch failed at 0005 . When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". > git diff-files :100644 100644 57156597cffa5f962030ed08a02ce58ddadd4034 0000000000000000000000000000000000000000 M :100644 100644 7e5864955f6fab817e9345487d536f9917c1f59d 0000000000000000000000000000000000000000 M :100644 100644 fe43d7699d63b305796bbbcd2ca7f1203f55c357 0000000000000000000000000000000000000000 M :100644 100644 952efbee4ef3de93e18ee714927c4e62280f0474 0000000000000000000000000000000000000000 M :100644 100644 e0200cb978e136ed04a173019bf233d048bdbb9f 0000000000000000000000000000000000000000 M :100644 100644 ec0f2e8113f3041e79d47f73f06932317c29b757 0000000000000000000000000000000000000000 M :100644 100644 f3118e5a547624ed3adf3adc569ccf819828f0f3 0000000000000000000000000000000000000000 M :100644 100644 4fb2917de4fcd8f4dbe5f4c4e9bdf23b8e821bc4 0000000000000000000000000000000000000000 M :100644 100644 9f4a78d31b6d0f73449eebe847beffa1795460ca 0000000000000000000000000000000000000000 M :100644 100644 20d3e4dad060c94d1d99f92b9cd67875a31f08d6 0000000000000000000000000000000000000000 M :100644 100644 6e59bdd1deaf98a9582c703dc38e68949f871c10 0000000000000000000000000000000000000000 M On Jun 15, 2012, at 9:08 AM, Jeff King 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. > > 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 ``` ## Eric Gillum, 2012-06-29 17:55 Subject: Re: git rebase keeps saying local changes would conflict..what changes? Message-ID: <5EEEC2B3-99E7-43A5-B6A7-903A7E8DA056@color.com> URL: https://gitlist.dev/e/5EEEC2B3-99E7-43A5-B6A7-903A7E8DA056%40color.com In-Reply-To: <890895A7-9DB5-4FD5-A45B-03151236FD70@color.com> ``` 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: > Applying: > Applying: > Applying: > Applying: > Using index info to reconstruct a base tree... > :124: trailing whitespace. > :125: trailing whitespace. > :218: trailing whitespace. > :278: trailing whitespace. > :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: > > > > > Please, commit your changes or stash them before you can merge. > Aborting > Failed to merge in the changes. > Patch failed at 0005 . > > When you have resolved this problem run "git rebase --continue". > If you would prefer to skip this patch, instead run "git rebase --skip". > To check out the original branch and stop rebasing run "git rebase --abort". > >> git diff-files > :100644 100644 57156597cffa5f962030ed08a02ce58ddadd4034 0000000000000000000000000000000000000000 M > :100644 100644 7e5864955f6fab817e9345487d536f9917c1f59d 0000000000000000000000000000000000000000 M > :100644 100644 fe43d7699d63b305796bbbcd2ca7f1203f55c357 0000000000000000000000000000000000000000 M > :100644 100644 952efbee4ef3de93e18ee714927c4e62280f0474 0000000000000000000000000000000000000000 M > :100644 100644 e0200cb978e136ed04a173019bf233d048bdbb9f 0000000000000000000000000000000000000000 M > :100644 100644 ec0f2e8113f3041e79d47f73f06932317c29b757 0000000000000000000000000000000000000000 M > :100644 100644 f3118e5a547624ed3adf3adc569ccf819828f0f3 0000000000000000000000000000000000000000 M > :100644 100644 4fb2917de4fcd8f4dbe5f4c4e9bdf23b8e821bc4 0000000000000000000000000000000000000000 M > :100644 100644 9f4a78d31b6d0f73449eebe847beffa1795460ca 0000000000000000000000000000000000000000 M > :100644 100644 20d3e4dad060c94d1d99f92b9cd67875a31f08d6 0000000000000000000000000000000000000000 M > :100644 100644 6e59bdd1deaf98a9582c703dc38e68949f871c10 0000000000000000000000000000000000000000 M > > > On Jun 15, 2012, at 9:08 AM, Jeff King 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. >> >> 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 > ```