Well, not "the same" but that my changes have been merged...
K
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
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
