interactive rebase of binary files?

interactive rebase of binary files?

[Phil Lawrence]

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

Re: interactive rebase of binary files?

[Jeff King]

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