I've been using Git on Windows (msysgit) to track changes for some design work I've been doing.
Today I've been working on a different PC (with remote repo brian) and I'm now trying to merge the edits done today back into my regular local version on my laptop.
On my laptop, I've used git pull brian master to pull the changes into my local version. Everything was fine apart from the main InDesign document - this shows as a conflict.
The version on the PC (brian) is the latest one that I want to keep but I don't know what commands tells the repo to use this one.
I tried directly copying the file across onto my laptop but this seems to break the whole merge process.
Can anyone point me in the right direction?
This question is related to
git
merge-conflict-resolution
This procedure is to resolve binary file conflicts after you have submitted a pull request to Github:
On Github, on your pull request, the conflict should disappear.
From the git checkout docs
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
--ours
--theirs
When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths.The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using
-fwill ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using--oursor--theirs. With-m, changes made to the working tree file can be discarded to re-create the original conflicted merge result.
I came across a similar problem (wanting to pull a commit that included some binary files which caused conflicts when merged), but came across a different solution that can be done entirely using git (i.e. not having to manually copy files over). I figured I'd include it here so at the very least I can remember it the next time I need it. :) The steps look like this:
% git fetch
This fetches the latest commit(s) from the remote repository (you may need to specify a remote branch name, depending on your setup), but doesn't try to merge them. It records the the commit in FETCH_HEAD
% git checkout FETCH_HEAD stuff/to/update
This takes the copy of the binary files I want and overwrites what's in the working tree with the version fetched from the remote branch. git doesn't try to do any merging, so you just end up with an exact copy of the binary file from the remote branch. Once that's done, you can add/commit the new copy just like normal.
You have to resolve the conflict manually (copying the file over) and then commit the file (no matter if you copied it over or used the local version) like this
git commit -a -m "Fix merge conflict in test.foo"
Git normally autocommits after merging, but when it detects conflicts it cannot solve by itself, it applies all patches it figured out and leaves the rest for you to resolve and commit manually. The Git Merge Man Page, the Git-SVN Crash Course or this blog entry might shed some light on how it's supposed to work.
Edit: See the post below, you don't actually have to copy the files yourself, but can use
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
to select the version of the file you want. Copying / editing the file will only be necessary if you want a mix of both versions.
Please mark mipadis answer as the correct one.
my case seems like a bug.... using git 2.21.0
I did a pull... it complained about binary files:
warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.
And then nothing in any of the answers here resulted in any output that made any sense.
If I look at which file I have now... it's the one I edited. If I do either:
git checkout --theirs -- <path>
git checkout --ours -- <path>
I get output:
Updated 0 paths from the index
and I still have my version of the file. If I rm and then checkout, It'll say 1 instead, but it still gives me my version of the file.
git mergetool says
No files need merging
and git status says
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
One option is to undo the commit... but I was unlucky and I had many commits, and this bad one was the first. I don't want to waste time repeating that.
so to solve this madness:
I just ran
git commit
which loses the remote version, and probably wastes some space storing an extra binary file... then
git checkout <commit where the remote version exists> <path>
which gives me back the remote version
then edited the file again...and then commit and push, which again probably means wasting space with another copy of the binary file.
I came across a similar problem (wanting to pull a commit that included some binary files which caused conflicts when merged), but came across a different solution that can be done entirely using git (i.e. not having to manually copy files over). I figured I'd include it here so at the very least I can remember it the next time I need it. :) The steps look like this:
% git fetch
This fetches the latest commit(s) from the remote repository (you may need to specify a remote branch name, depending on your setup), but doesn't try to merge them. It records the the commit in FETCH_HEAD
% git checkout FETCH_HEAD stuff/to/update
This takes the copy of the binary files I want and overwrites what's in the working tree with the version fetched from the remote branch. git doesn't try to do any merging, so you just end up with an exact copy of the binary file from the remote branch. Once that's done, you can add/commit the new copy just like normal.
I use Git Workflow for Excel - https://www.xltrail.com/blog/git-workflow-for-excel application to resolve most of my binary files related merge issues. This open-source app helps me to resolve issues productively without spending too much time and lets me cherry pick the right version of the file without any confusion.
This procedure is to resolve binary file conflicts after you have submitted a pull request to Github:
On Github, on your pull request, the conflict should disappear.
You can also overcome this problem with
git mergetool
which causes git to create local copies of the conflicted binary and spawn your default editor on them:
{conflicted}.HEAD{conflicted}{conflicted}.REMOTEObviously you can't usefully edit binaries files in a text editor. Instead you copy the new {conflicted}.REMOTE file over {conflicted} without closing the editor. Then when you do close the editor git will see that the undecorated working-copy has been changed and your merge conflict is resolved in the usual way.
To resolve by keeping the version in your current branch (ignore the version from the branch you are merging in), just add and commit the file:
git commit -a
To resolve by overwriting the version in your current branch with the version from the branch you are merging in, you need to retrieve that version into your working directory first, and then add/commit it:
git checkout otherbranch theconflictedfile
git commit -a
my case seems like a bug.... using git 2.21.0
I did a pull... it complained about binary files:
warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.
And then nothing in any of the answers here resulted in any output that made any sense.
If I look at which file I have now... it's the one I edited. If I do either:
git checkout --theirs -- <path>
git checkout --ours -- <path>
I get output:
Updated 0 paths from the index
and I still have my version of the file. If I rm and then checkout, It'll say 1 instead, but it still gives me my version of the file.
git mergetool says
No files need merging
and git status says
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
One option is to undo the commit... but I was unlucky and I had many commits, and this bad one was the first. I don't want to waste time repeating that.
so to solve this madness:
I just ran
git commit
which loses the remote version, and probably wastes some space storing an extra binary file... then
git checkout <commit where the remote version exists> <path>
which gives me back the remote version
then edited the file again...and then commit and push, which again probably means wasting space with another copy of the binary file.
You have to resolve the conflict manually (copying the file over) and then commit the file (no matter if you copied it over or used the local version) like this
git commit -a -m "Fix merge conflict in test.foo"
Git normally autocommits after merging, but when it detects conflicts it cannot solve by itself, it applies all patches it figured out and leaves the rest for you to resolve and commit manually. The Git Merge Man Page, the Git-SVN Crash Course or this blog entry might shed some light on how it's supposed to work.
Edit: See the post below, you don't actually have to copy the files yourself, but can use
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
to select the version of the file you want. Copying / editing the file will only be necessary if you want a mix of both versions.
Please mark mipadis answer as the correct one.
If the binary is something more than a dll or something that can be edited directly like an image, or a blend file (and you don't need to trash/select one file or the other) a real merge would be some like:
I suggest searching for a diff tool oriented to what are your binary file, for example, there are some free ones for image files for example
and compare them.
If there is no diff tool out there for comparing your files, then if you have the original generator of the bin file (that is, there exist an editor for it... like blender 3d, you can then manually inspect those files, also see the logs, and ask the other person what you should include) and do output of the files with https://git-scm.com/book/es/v2/Git-Tools-Advanced-Merging#_manual_remerge
$ git show :1:hello.blend > hello.common.blend
$ git show :2:hello.blend > hello.ours.blend
$ git show :3:hello.blend > hello.theirs.blend
You have to resolve the conflict manually (copying the file over) and then commit the file (no matter if you copied it over or used the local version) like this
git commit -a -m "Fix merge conflict in test.foo"
Git normally autocommits after merging, but when it detects conflicts it cannot solve by itself, it applies all patches it figured out and leaves the rest for you to resolve and commit manually. The Git Merge Man Page, the Git-SVN Crash Course or this blog entry might shed some light on how it's supposed to work.
Edit: See the post below, you don't actually have to copy the files yourself, but can use
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
to select the version of the file you want. Copying / editing the file will only be necessary if you want a mix of both versions.
Please mark mipadis answer as the correct one.
mipadi's answer didn't quite work for me, I needed to do this :
git checkout --ours path/to/file.bin
or, to keep the version being merged in:
git checkout --theirs path/to/file.bin
then
git add path/to/file.bin
And then I was able to do "git mergetool" again and continue onto the next conflict.
I've come across two strategies for managing diff/merge of binary files with Git on windows.
Tortoise git lets you configure diff/merge tools for different file types based on their file extensions. See 2.35.4.3. Diff/Merge Advanced Settings http://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html. This strategy of course relys on suitable diff/merge tools being available.
Using git attributes you can specify a tool/command to convert your binary file to text and then let your default diff/merge tool do it's thing. See http://git-scm.com/book/it/v2/Customizing-Git-Git-Attributes. The article even gives an example of using meta data to diff images.
I got both strategies to work with binary files of software models, but we went with tortoise git as the configuration was easy.
I use Git Workflow for Excel - https://www.xltrail.com/blog/git-workflow-for-excel application to resolve most of my binary files related merge issues. This open-source app helps me to resolve issues productively without spending too much time and lets me cherry pick the right version of the file without any confusion.
If the binary is something more than a dll or something that can be edited directly like an image, or a blend file (and you don't need to trash/select one file or the other) a real merge would be some like:
I suggest searching for a diff tool oriented to what are your binary file, for example, there are some free ones for image files for example
and compare them.
If there is no diff tool out there for comparing your files, then if you have the original generator of the bin file (that is, there exist an editor for it... like blender 3d, you can then manually inspect those files, also see the logs, and ask the other person what you should include) and do output of the files with https://git-scm.com/book/es/v2/Git-Tools-Advanced-Merging#_manual_remerge
$ git show :1:hello.blend > hello.common.blend
$ git show :2:hello.blend > hello.ours.blend
$ git show :3:hello.blend > hello.theirs.blend
To resolve by keeping the version in your current branch (ignore the version from the branch you are merging in), just add and commit the file:
git commit -a
To resolve by overwriting the version in your current branch with the version from the branch you are merging in, you need to retrieve that version into your working directory first, and then add/commit it:
git checkout otherbranch theconflictedfile
git commit -a
You can also overcome this problem with
git mergetool
which causes git to create local copies of the conflicted binary and spawn your default editor on them:
{conflicted}.HEAD{conflicted}{conflicted}.REMOTEObviously you can't usefully edit binaries files in a text editor. Instead you copy the new {conflicted}.REMOTE file over {conflicted} without closing the editor. Then when you do close the editor git will see that the undecorated working-copy has been changed and your merge conflict is resolved in the usual way.
You have to resolve the conflict manually (copying the file over) and then commit the file (no matter if you copied it over or used the local version) like this
git commit -a -m "Fix merge conflict in test.foo"
Git normally autocommits after merging, but when it detects conflicts it cannot solve by itself, it applies all patches it figured out and leaves the rest for you to resolve and commit manually. The Git Merge Man Page, the Git-SVN Crash Course or this blog entry might shed some light on how it's supposed to work.
Edit: See the post below, you don't actually have to copy the files yourself, but can use
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
to select the version of the file you want. Copying / editing the file will only be necessary if you want a mix of both versions.
Please mark mipadis answer as the correct one.
From the git checkout docs
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
--ours
--theirs
When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths.The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using
-fwill ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using--oursor--theirs. With-m, changes made to the working tree file can be discarded to re-create the original conflicted merge result.
mipadi's answer didn't quite work for me, I needed to do this :
git checkout --ours path/to/file.bin
or, to keep the version being merged in:
git checkout --theirs path/to/file.bin
then
git add path/to/file.bin
And then I was able to do "git mergetool" again and continue onto the next conflict.
Source: Stackoverflow.com