Re: interactive rebase of binary files?

From: Jeff King <peff@peff.net>
Date: Aug 1, 2009, 05:15 UTC
Message-ID: <20090801051559.GA26580@sigill.intra.peff.net>
In-Reply-To: <530ac78e0907312058i1fbc3685qad060d5c01f5b8ac@mail.gmail.com>

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