Re: [PATCH] GIT commit statistics.

From: Junio C Hamano <junkio@cox.net>
Date: Nov 14, 2005, 06:06 UTC
Message-ID: <7vwtjb4vc4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90511132001x6a9109fk17593b7ceaf3177e@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> writes:

Show 8 quoted lines

> On 11/14/05, Junio C Hamano <junkio@cox.net> 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.