50

For some reason lately, every time I pull and get a merge conflict, running git mergetool reports "No files need merging":

$ git pull
First, rewinding head to replay your work on top of it...
Applying: replaced home button with Cancel
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
error: Your local changes to the following files would be overwritten by merge:
    Classes/Controllers/HomeController.m
Please, commit your changes or stash them before you can merge.
Aborting
Failed to merge in the changes.
Patch failed at 0002 moved rollback into cancel button in log watching

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 mergetool
No files need merging

If I run git rebase --abort and pull again, either the same thing happens on a different conflict, or the pull succeeds with no merge conflict. There are no remote changes between these pulls, so it's not as though the conflict went away.

Here's how this branch and the remote are configured:

[branch "develop"]
        remote = origin
        merge = refs/heads/develop
        rebase = true
[remote "origin"]
        url = <my repo url>
        fetch = +refs/heads/*:refs/remotes/origin/*
Christopher Pickslay
  • 17,523
  • 6
  • 79
  • 92
  • What do `git status` and `git ls-files -u` report? – Mark Longair Oct 22 '11 at 08:48
  • @MarkLongair let mecheck the next time I do a pull. – Christopher Pickslay Oct 23 '11 at 16:32
  • @MarkLongair it happened to me again. git status reported: # On branch develop # Your branch and 'origin/develop' have diverged, # and have 5 and 3 different commit(s) each, respectively. # nothing to commit (working directory clean) git ls-files -u reports nothing. – Christopher Pickslay Oct 26 '11 at 04:27
  • What version of git are you using? It looks as if you have `branch.autosetuprebase` or `branch..rebase` set, since `git pull` is causing a rebase - however, in my version of git it will refuse to pull with rebase if you have local changes, as the error message you quote indicates that you do. – Mark Longair Oct 26 '11 at 11:01
  • @MarkLongair I'm using 1.7.7. I do have rebase set to true on the branch, as you can see above. git will refuse to pull with rebase if you have uncommitted changes, but not if you have committed changes--otherwise there would be nothing to rebase. All my changes were committed. I've worked with `autosetuprebase` for a while, but only recently run into this issue. Normally I pull, and if there's a merge conflict, I can always run `git mergetool`. – Christopher Pickslay Oct 26 '11 at 23:35
  • git clearly does think that you have local changes from the message `error: Your local changes to the following files would be overwritten by merge`. If you're using a Mac, perhaps [this answer to a similar question](http://stackoverflow.com/questions/5074136/git-rebase-fails-your-local-changes-to-the-following-files-would-be-overwritte/5255710#5255710) will fix it for you. – Mark Longair Oct 27 '11 at 07:00
  • @MarkLongair yeah that message confused me too. That other question does look like what's happening to me. I'll try it out. – Christopher Pickslay Oct 27 '11 at 21:25
  • Thanks @MarkLongair. It looks like the question you linked solved my problem. – Christopher Pickslay Oct 28 '11 at 22:02
  • Great, I'm glad to hear that. It's certainly a confusing situation. – Mark Longair Oct 28 '11 at 22:11

7 Answers7

41

This fixed it for me:
git mergetool .

I found this fix here

Josh
  • 2,142
  • 2
  • 23
  • 20
17

It looks like my problem had to do with file timestamps. Thanks to this SO answer suggested by Mark Longair, the following setting fixed it for me:

git config --global core.trustctime false
Community
  • 1
  • 1
Christopher Pickslay
  • 17,523
  • 6
  • 79
  • 92
12

Trivial solution

which worked for me: Git creates some merge related files in the very same directory where the conflicted file is, so remember to run git mergetool in correct path.

IProblemFactory
  • 9,551
  • 8
  • 50
  • 66
5

Solution 1:

$git config --global core.trustctime false

If false, the ctime differences between the index and the working copy are ignored; useful when the inode change time is regularly modified by something outside Git (file system crawlers and some backup systems). and core.trustctime is true by default.

Solution 2: just:

$git rebase --skip

It's OK for you to skip it

lijinma
  • 2,914
  • 1
  • 23
  • 22
  • 1
    True that it's safe to skip, but then I'd have to think about whether the current patch is OK to skip every time I see it. I'd rather avoid the error altogether. – Christopher Pickslay Sep 27 '12 at 19:01
  • 1
    You are right, Pickslay, avoiding the error is energy-efficient option :) – lijinma Oct 08 '12 at 03:23
  • If some process is changing file modification times for backup or indexing purposes, it's time to get rid of such a beast. Neither of those jobs require changing modification time! I would suggest fixing the cause instead of working around the mess caused by those processes. – Mikko Rantalainen Apr 29 '13 at 06:21
0

In my case the issue was that I had another console window open and was running the application (based on create-react-app, with hot reloading) in that window.

Killing the process and closing the other window, then aborting the rebase and retrying worked for me.

TrueWill
  • 25,132
  • 10
  • 101
  • 150
0

Could it be that you must first run merge? Then if there are merge conflicts to resolve, you can run mergetool. But until there are created as the results of an incomplete merge, I think mergetool will simply report there is nothing to merge.

mitch
  • 396
  • 1
  • 7
  • 14
0

Merge tools are better at resolving conflicts than stock git. It can't be too opinionated. For example Beyond Compare is syntax aware and will do a lot for you. If you have it configured right, you can just compile and run your solution to test. If it's all good, then just git add -A and git rebase --continue. What you are experiencing is normal. Double check your "trust mergetool exit code" setting:

git config --global mergetool.trustExitCode true

Note: the -A option in git add will stage all changes including deletions and new, untracked files.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Yes, I have trustExitCode set to true. It sounds like you're saying that when I do a pull, git uses the configured mergetool (diffmerge in my case), to attempt a non-interactive merge, and in this case the merge is successful. Is that right? I've always interpreted "Failed to merge in the changes" to mean I needed to manually run git mergetool. – Christopher Pickslay Oct 22 '11 at 05:37
  • No, when you do a pull it just reports conflicts. When you call mergetool, that's when the mergetool fixes the conflict automatically and returns to the command line after it fixed the conflicts. Your next step is to now test your solution to double check that the tools did not make a mistake. If everything is still running, `git rebase --continue`. – Adam Dymitruk Oct 22 '11 at 06:32
  • I don't think this is right - if you look `git-mergetool.sh` the merge tool won't have been called at all if you get the error message "No files need merging". I think we need more information from the questioner. – Mark Longair Oct 22 '11 at 08:57
  • Interesting. I'll have to take a look. Thanks. – Adam Dymitruk Oct 22 '11 at 09:52
  • @AdamDymitruk I can't just git rebase --continue at this point. I get "No changes - did you forget to use 'git add'?" – Christopher Pickslay Oct 26 '11 at 04:32
  • @AdamDymitruk in my case `git add` reports that there are no unstaged changes when it's in this state. It seems my only option is to abort the rebase and try again. What's weird is that the result is not deterministic--either the merge succeeds the second time or fails on a different conflict. – Christopher Pickslay Oct 26 '11 at 23:38
  • what mergetool are you using? – Adam Dymitruk Oct 26 '11 at 23:42
  • did you see any documentation for configuring git for it? Can you try P4Merge and see if that works? This way we can see if it's something with Git or your merge tools. – Adam Dymitruk Oct 27 '11 at 21:31