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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html