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 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to