On Oct 13, 8:10 pm, Ken <kohud...@gmail.com> wrote:

> I need some help.  I have two branches: "master" and "add_articles".
> I've been doing my work in add_articles and I wanted to merge the
> changes in to master prior to doing a deploy of my application.
> Here's the sequence of events:
> git merge add_articles - gave me this error:
> warning: Cannot merge binary files: HEAD:public/images/
> NewMexico_jul_1.jpg vs. add_articles:public/images/NewMexico_jul_1.jpg

Well, I think I failed to explain the general idea in a clear way, so
let's do that in another post.
To resolve a conflict, you have to:
1) Make sure the file has sensible contents and it is in the
"resolved" state from the "human" (yours) point of view.
2) Make sure that file is resolved from the Git's point of view.

Step (2) is the simplest -- just git-add the file. That's what Git
hints you about when you run git-status while resolving the conflict.

Step (1) is harder to perform.
First, when dealing with text files, in case of a conflict, Git
replaces conflicting parts of the file with sets of chunks ("theirs"
and "ours") delimited by special conflict markers. This provides for
easy comparison of conflicting bits, but at the same time it means
it's absolutely pointless to git-add such a file until its contents is
manually tweaked and conflicting markers and unneded pieces removed.
For binary files, Git can't do the same thing, so it just raises its
hands leaving the "ours" contents of that file intact. Now, in theory,
you can compare both versions of such files using some tool specific
to their format, if such tool exists, and somehow actually merge the
changes. But usually one just decides which of the two versions is
"actual" and now there's the need to update the file's contents to
that version.
For this you use git-checkout which is "overloaded" to perform a
couple of different tasks -- with updating contents of specific files
being one of them.
To specify the version you need you either use old
voodoo :STAGE:FILENAME syntax or more recent and more conveinent --
theirs and --ours options.

You can read up on that syntax involving stage numbers in the git-rev-
parse manual page ("SPECIFYING REVISIONS" section).

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to