git mergetool reports "No files need merging"

Asked 21/10, 2011 at 19:56 Answered 18/3, 2019 at 11:0

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

Preussen answered 21/10, 2011 at 19:56 Comment(9)

What do git status and git ls-files -u report? – Milkfish 22/10, 2011 at 8:48

@MarkLongair let mecheck the next time I do a pull. – Preussen 23/10, 2011 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. – Preussen 26/10, 2011 at 4:27

What version of git are you using? It looks as if you have branch.autosetuprebase or branch.<name>.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. – Milkfish 26/10, 2011 at 11:1

@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. – Preussen 26/10, 2011 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 will fix it for you. – Milkfish 27/10, 2011 at 7:0

@MarkLongair yeah that message confused me too. That other question does look like what's happening to me. I'll try it out. – Preussen 27/10, 2011 at 21:25

Thanks @MarkLongair. It looks like the question you linked solved my problem. – Preussen 28/10, 2011 at 22:2

Great, I'm glad to hear that. It's certainly a confusing situation. – Milkfish 28/10, 2011 at 22:11

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

Preussen answered 28/10, 2011 at 22:6 Comment(1)

Interesting. Any side effects of this you think? – Abert 28/9, 2023 at 23:3

This fixed it for me:
git mergetool .

I found this fix here

Bombazine answered 20/3, 2018 at 22:35 Comment(4)

Worked on git version 2.18.0. Now we just need to understand why. – Titian 13/6, 2019 at 15:20

For me this just says "no files need merging". Yet "git rebase --continue" says "You must edit all merge conflicts and then mark them as resolved using git add". So one of these is wrong I guess? – Shantelleshantha 21/9, 2023 at 4:6

Note that this only works if you're in a parent folder of the files that need merging. I.e. if the file(s) that need merging are in GitRoot/Folder1, then this won't work if you're in GitRoot/AnotherFolder2. Easiest to only do this while in the root of the git archive. – Fennell 5/4 at 9:40

Thanks. This solution worked for me. Afaik: In my case, I had rerere enabled. Thanks to this feature, my rebased commit was remembered and git does auto-merge to speed up the process. I need to double-check and accept the merged files. – Infighting 16/5 at 13:36

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

Preussen answered 28/10, 2011 at 22:6 Comment(1)

Interesting. Any side effects of this you think? – Abert 28/9, 2023 at 23:3

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.

Ulcerate answered 28/11, 2014 at 15:52 Comment(2)

please explain this – Bailly 25/11, 2018 at 10:6

@Bailly merge and mergetool work in the sub-directory you are currently in, it does not run on the whole repository – Twana 28/11, 2018 at 17:4

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

Lazybones answered 27/9, 2012 at 4:43 Comment(3)

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. – Preussen 27/9, 2012 at 19:1

You are right, Pickslay, avoiding the error is energy-efficient option :) – Lazybones 8/10, 2012 at 3: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. – Storied 29/4, 2013 at 6:21

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.

Dietz answered 21/10, 2011 at 20:39 Comment(8)

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. – Preussen 22/10, 2011 at 5: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. – Dietz 22/10, 2011 at 6: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. – Milkfish 22/10, 2011 at 8:57

Interesting. I'll have to take a look. Thanks. – Dietz 22/10, 2011 at 9:52

@AdamDymitruk I can't just git rebase --continue at this point. I get "No changes - did you forget to use 'git add'?" – Preussen 26/10, 2011 at 4: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. – Preussen 26/10, 2011 at 23:38

what mergetool are you using? – Dietz 26/10, 2011 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. – Dietz 27/10, 2011 at 21:31

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.

Diffractometer answered 12/12, 2017 at 15:29 Comment(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.

Barbera answered 18/3, 2019 at 11:0 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags