Well, not "the same" but that my changes have been merged...
On Oct 13, 10:04 am, Ken <kohud...@gmail.com> wrote:
> Thank you for the detailed explanation. I appreciate it.
> I did the following and it seemed to work:
> git checkout add_articles public/images/NewMexico_jul_1.jpg
> git add public/images/NewMexico_jul_1.jpg
> git commit
> Is there some way I can compare the "master" branch with the
> "add_articles" branch to validate that they are indeed the same?
> Thanks, Ken
> On Oct 13, 9:58 am, Konstantin Khomoutov <khomou...@gmail.com> wrote:
> > 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