With the help of some friends, I now have an understanding of how to
tease interleaved commits out of a branch (dev, branched from master),
into two new branches (foo and bar, branched from dev):
git checkout dev
git checkout -b foo
git rebase -i master #rebase everything SINCE master
etc., repeat for bar...
However, there is a problem with binary files. For example, if I
specify "edit" in the git-rebase-todo list for one of the binary file
commits, only one version of the binary file is presented to me in the
working copy. If it were a text file, I'd expect to see the standard
conflict stuff within the one file. I'd edit and save that one file.
However, in the case of binary files, should I not see binary_file.a
and binary_file.b both in the working copy, so that I can compare and
pick a winner (or edit one of them into a winner)?
More likely, my expectations are due to my ignorance, and someone can
point me to the "git" way of doing this. Please?
Phil Lawrence
On Fri, Jul 31, 2009 at 10:58:58PM -0500, Phil Lawrence wrote:
However, there is a problem with binary files. For example, if I
specify "edit" in the git-rebase-todo list for one of the binary file
commits, only one version of the binary file is presented to me in the
working copy. If it were a text file, I'd expect to see the standard
conflict stuff within the one file. I'd edit and save that one file.
However, in the case of binary files, should I not see binary_file.a
and binary_file.b both in the working copy, so that I can compare and
pick a winner (or edit one of them into a winner)?
More likely, my expectations are due to my ignorance, and someone can
point me to the "git" way of doing this. Please?
During a merge conflict, the index stages are populated with the various
versions of the file you are looking for. The simplest way to access
them is probably:
$ git show :1:$filename ;# the common ancestor
$ git show :2:$filename ;# upstream version
$ git show :3:$filename ;# version from rebasing branch
It's a bit tricky to find in the documentation, though. You have to
first realize that git-rebase is basically trying to do a merge behind
the scenes, and then find the "how to resolve conflicts" section of "git
help merge". And then realize that the usual "ours" and "theirs" stages
of 2 and 3 are reversed, since you are really merging your work onto the
upstream branch. So probably there is room to improve the documentation,
but I'm not sure of the best way.
-Peff