Re: [PATCH] GIT commit statistics.

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Nov 14, 2005, 08:51 UTC
Message-ID: <46a038f90511140051o1fa5ef7cyb9dd723fb8161ef9@mail.gmail.com>
In-Reply-To: <7vwtjb4vc4.fsf@assigned-by-dhcp.cox.net>

On 11/14/05, Junio C Hamano <junkio@cox.net> wrote:

Show 6 quoted lines

> 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'm curious. What would be the advantages of this over git-read-tree -m for use within a single repo? I keep thinking that I need an intra-repo way of doing it (arguably faster and more reliable), instead of git-format-patch|git-am, which is less reliable and slower.

OTOH, if this is heading towards teaching git-am how to apply changes to binary files based on known SHA1s, this will give birth to a type of patch that applies only if you have the objects beforehand. Is that enough to get by? Perhaps we need a format to fully describe binary files?

> 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:

That's quite a bit of C hacking... I'm game for all the Perl and shell scripts in git, but I know better than start learning C in _this_ project with you, Linus and the whole list watching me make the fool ;-)

So noone hacks this bit of C you are proposing I'll eventually get something done with cg-update and git-rebase.

In the meantime, the user experience of working with a small team and a shared repo has improved significantly by switching from cg-update to cg-fetch && git-rebase origin. So much so that I suspect that it'd be a big win for cg-update to default to rebase on merges from 'origin'.

cheers,

martin