 <p>There are two straightforward options for doing this within Git (without using any of the p4 tools). One, probably the better one in general, is (as <a href="http://stackoverflow.com/questions/37929779/git-how-to-merge-individual-file-that-cannot-be-inspected#comment63311177_37929779">PetSerAl answered in a comment</a>):</p> <pre><code>git checkout --theirs "path"; git add "path" </code></pre> <p>The first part, <code>git checkout --theirs</code>, extracts the other branch version (the one you are calling "remote" here; that's one of several names various tools use to try to tell which file is which) into the work-tree. The second part, <code>git add</code>, marks the file as "resolved".</p> <p>Another (not quite as good in some ways) method is:</p> <pre><code>git checkout MERGE_HEAD "path" </code></pre> <p>This looks—and is!—simpler: it tells Git to extract the <code>MERGE_HEAD</code> version (the <code>--theirs</code> or "remote" version) of the given path, and as a side effect, marks the file resolved.</p> <p>In <em>most</em> cases (including yours, here) these two do exactly the same thing.</p> <h3>When are they different?</h3> <p>The one case where they do something different occurs when Git decides that a file was renamed. Consider the following example:</p> <pre><code>$ mkdir mergetest; cd mergetest; git init Initialized empty Git repository in [...]/mergetest/.git/ $ echo repo for merge example &gt; README $ git add README; git commit -m initial [master (root-commit) 74ad4af] initial 1 file changed, 1 insertion(+) create mode 100644 README </code></pre> <p>We now have a repository with no files yet (except for a README). Let's make a file with some fairly significant content that Git can detect easily enough even if we modify and rename it:</p> <pre><code>$ cp /etc/termcap termcap; chmod 644 termcap $ git add termcap; git commit -m 'add termcap' [master de3d189] add termcap 1 file changed, 4666 insertions(+) create mode 100644 termcap </code></pre> <p>Now let's set up to have two branches, and make changes to the termcap copy in each branch, so that we can get a merge conflict.</p> <pre><code>$ git branch A; git checkout -b B Switched to a new branch 'B' </code></pre> <p>In our B branch, let's change the last few lines a bit:</p> <pre><code>$ tail -3 termcap # # END OF TERMCAP # ------------------------ $ ed termcap 208311 $-1s/TERMCAP/LINE/p # END OF LINE w 208308 q $ git add termcap; git commit -m 'Tron MCP says END OF LINE!' [B 9f40f2d] Tron MCP says END OF LINE! 1 file changed, 1 insertion(+), 1 deletion(-) </code></pre> <p>Now we'll change the file in an incompatible way in branch A:</p> <pre><code>$ git checkout A Switched to branch 'A' $ ed termcap 208311 $-1s/TERMCAP/FILE/p # END OF FILE w 208308 q $ git add termcap; git commit -m 'incompatible change' [A 9aae164] incompatible change 1 file changed, 1 insertion(+), 1 deletion(-) </code></pre> <p>We're almost ready to merge, but that will be somewhat boring, so let's make one more change now: we'll rename <code>termcap</code>.</p> <pre><code>$ git mv termcap stocking-cap $ git commit -m rename [A 713eddd] rename 1 file changed, 0 insertions(+), 0 deletions(-) rename termcap =&gt; stocking-cap (100%) </code></pre> <p>Now we can try to merge from B:</p> <pre><code>$ git merge B Auto-merging stocking-cap CONFLICT (content): Merge conflict in stocking-cap Automatic merge failed; fix conflicts and then commit the result. $ git status On branch A You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add &lt;file&gt;..." to mark resolution) both modified: stocking-cap no changes added to commit (use "git add" and/or "git commit -a") </code></pre> <p>Note that Git now refers to the file, not as <code>termcap</code>, but as <code>stocking-cap</code>. The conflict is between our Tron-ish END OF LINE phrase, which we applied to a file named <code>termcap</code>, and our <code>END OF FILE</code> phrase, which we applied to <code>termcap</code> as well but then we renamed to <code>stocking-cap</code>.</p> <p>If we attempt to check out <code>termcap</code> from <code>MERGE_HEAD</code>, we get an error instead:</p> <pre><code>$ git checkout MERGE_HEAD stocking-cap error: pathspec 'stocking-cap' did not match any file(s) known to git. </code></pre> <p>The file is known, in the tip of branch <code>B</code> (aka <code>MERGE_HEAD</code>), as <code>termcap</code>, not as <code>stocking-cap</code>. But if we <code>git checkout --theirs</code> it works:</p> <pre><code>$ git checkout --theirs stocking-cap $ tail -3 stocking-cap # # END OF LINE # ------------------------ </code></pre> <p>There we go: the file is still renamed, but we got "their" version, which in MERGE_HEAD is known as <code>termcap</code>. The file is still in unmerged state though, as <code>git status</code> will show (try it), or as seen in <code>git ls-files --stage</code>:</p> <pre><code>$ git ls-files --stage 100644 666e31eff490e17863f3261a0c16df0cdf8ca69f 0 README 100644 30e251d0e75b4905449a052b5f04e316b15ffd46 1 stocking-cap 100644 941c1fa9c08e7dc0c5b8fd8e033708e6a66e4166 2 stocking-cap 100644 f6282a43f57b2acf2561ccbc58b817e21ae13b07 3 stocking-cap </code></pre> <p>We must <code>git add stocking-cap</code> to resolve it:</p> <pre><code>$ git add stocking-cap $ git status -s M stocking-cap </code></pre> <p>and now we can commit:</p> <pre><code>$ git commit -m 'completed the merge' [A c0a3dad] completed the merge </code></pre> <p>and view diffs:</p> <pre><code> $ git diff A B diff --git a/stocking-cap b/termcap similarity index 100% rename from stocking-cap rename to termcap </code></pre> <p>and logs:</p> <pre><code>$ git log --decorate --oneline --graph --all * c0a3dad (HEAD -&gt; A) completed the merge |\ | * 9f40f2d (B) Tron MCP says END OF LINE! * | 713eddd rename * | 9aae164 incompatible change |/ * de3d189 (master) add termcap * 74ad4af initial </code></pre> <p>and so on.</p> <h3>Recap</h3> <p>You may use <code>git checkout MERGE_HEAD</code>, which extracts the file from the other commit (<code>B</code> in our example here) and lets you skip the <code>git add</code> step, but requires the file name to be unchanged. Or, you may use <code>git checkout --theirs</code>, which extracts the file from the other commit, <em>and</em> handles renames, <em>but</em> forces you to <code>git add</code> the result.</p>