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 <[email protected]> wrote: > On Oct 13, 8:10 pm, Ken <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
