{"thread":{"id":"20326","subject":"interactive rebase of binary files?","startedAt":"2009-08-01T03:58:58Z","lastAt":"2009-08-01T05:15:59Z","messageCount":2,"participants":["Phil Lawrence","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"119315","messageId":"530ac78e0907312058i1fbc3685qad060d5c01f5b8ac@mail.gmail.com","threadId":"20326","inReplyTo":null,"subject":"interactive rebase of binary files?","fromName":"Phil Lawrence","fromEmail":"prlawrence@gmail.com","sentAt":"2009-08-01T03:58:58Z","receivedAt":"2009-08-01T03:58:58Z","isPatch":false,"sender":{"key":"prlawrence@gmail.com","avatar":"https://gravatar.com/avatar/352044d06dd8919a32522c18c712e0a8d07b8e8719c820b4b50ffb8f6f2fa1f0?d=mp&s=160"},"body":"With the help of some friends, I now have an understanding of how to\ntease interleaved commits out of a branch (dev, branched from master),\ninto two new branches (foo and bar, branched from dev):\n\ngit checkout dev\ngit checkout -b foo\ngit rebase -i master   #rebase everything SINCE master\netc., repeat for bar...\n\nHowever, there is a problem with binary files.  For example, if I\nspecify \"edit\" in the git-rebase-todo list for one of the binary file\ncommits, only one version of the binary file is presented to me in the\nworking copy.  If it were a text file, I'd expect to see the standard\nconflict stuff within the one file.  I'd edit and save that one file.\nHowever, in the case of binary files, should I not see binary_file.a\nand binary_file.b both in the working copy, so that I can compare and\npick a winner (or edit one of them into a winner)?\n\nMore likely, my expectations are due to my ignorance, and someone can\npoint me to the \"git\" way of doing this.  Please?\n\nPhil Lawrence\n"},{"id":"119316","messageId":"20090801051559.GA26580@sigill.intra.peff.net","threadId":"20326","inReplyTo":"530ac78e0907312058i1fbc3685qad060d5c01f5b8ac@mail.gmail.com","subject":"Re: interactive rebase of binary files?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-01T05:15:59Z","receivedAt":"2009-08-01T05:15:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 31, 2009 at 10:58:58PM -0500, Phil Lawrence wrote:\n\n> However, there is a problem with binary files.  For example, if I\n> specify \"edit\" in the git-rebase-todo list for one of the binary file\n> commits, only one version of the binary file is presented to me in the\n> working copy.  If it were a text file, I'd expect to see the standard\n> conflict stuff within the one file.  I'd edit and save that one file.\n> However, in the case of binary files, should I not see binary_file.a\n> and binary_file.b both in the working copy, so that I can compare and\n> pick a winner (or edit one of them into a winner)?\n> \n> More likely, my expectations are due to my ignorance, and someone can\n> point me to the \"git\" way of doing this.  Please?\n\nDuring a merge conflict, the index stages are populated with the various\nversions of the file you are looking for. The simplest way to access\nthem is probably:\n\n  $ git show :1:$filename ;# the common ancestor\n  $ git show :2:$filename ;# upstream version\n  $ git show :3:$filename ;# version from rebasing branch\n\nIt's a bit tricky to find in the documentation, though. You have to\nfirst realize that git-rebase is basically trying to do a merge behind\nthe scenes, and then find the \"how to resolve conflicts\" section of \"git\nhelp merge\". And then realize that the usual \"ours\" and \"theirs\" stages\nof 2 and 3 are reversed, since you are really merging your work onto the\nupstream branch. So probably there is room to improve the documentation,\nbut I'm not sure of the best way.\n\n-Peff\n"}]}