interactive rebase of binary files?

Phil Lawrence· Aug 1, 2009, 03:58 UTC · lore

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

Jeff King· Aug 1, 2009, 05:15 UTC · re: Phil Lawrence · lore

Re: interactive rebase of binary files?

On Fri, Jul 31, 2009 at 10:58:58PM -0500, Phil Lawrence wrote:

Show 11 quoted lines

> 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