From: Junio C Hamano Date: Mon, 14 Nov 2005 06:06:19 GMT Subject: Re: [PATCH] GIT commit statistics. Message-ID: <7vwtjb4vc4.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <46a038f90511132001x6a9109fk17593b7ceaf3177e@mail.gmail.com> Martin Langhoff writes: > On 11/14/05, Junio C Hamano wrote: >> In your message you indicated that you use "format-patch" piped >> to "am". I think that is a better approach than "rebase" these >> days > > Hmmm. But doesn't deal well with binary changes. We deal with a large > set of projects, and while we don't manage that many binary files, it > is just enough that I'll have to pass on only using format-patch. It shouldn't be too tricky to enhance "git am" (git-apply called at around line 49 in it) to grok binary differences for this purpose, because you would have both pre- and post-image blob in your object database, because the patch is being used only to replay what you have in your reository, and it records their abbreviated SHA1 name. I've never felt need to "merge" the binary files myself and had never got around doing this, but if you are interested, it would go something like this: . Make "index %.7s..%.7s" that abbreviates pre- and post- image blob SHA1s in diff.c configurable to spit out full 40 bytes. Call that option --full-index-sha1. . The updated "git rebase" that uses the "format-patch | am" I outlined would pass the --full-index-sha1 to format-patch (which is pased onto underlying diff-tree -p). . In apply.c, check if all of the following holds: * we have both the full 40-byte old_sha1_prefix[] and new_sha1_prefix[]; and * what the index records matches old_sha1_prefix[]; and * the new blob is found in the object database; and for such a path: * change parse_chunk() not to barf even on a binary patch. * change apply_data() to just declare the patch application result is the new blob recorded in the patch. Hmm.