Re: [PATCH] GIT commit statistics.

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

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

> I'm curious. What would be the advantages of this over git-read-tree
> -m for use within a single repo?

On a large tree I had an impression that applying patch and then falling back on 3-way is faster, but other than that, nothing, really. Just being able to use a single mechanism, which does not buy us much.

Show 5 quoted lines

> 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'd rather not see our "patch" go in the direction of recording both pre- and post-image of blob for binary files, which is what we would end up doing if we really want to do binary flexibly.

Well, that may be nice as an option, but not by default.

An option halfway in between would be to record the pre-image SHA1 and post- blob, perhaps compressed-uuencoded. This would limit us to the case that the recipient has not touched the binary file and replacing it, but in practice that might be enough.

I'm willing to do the C hackery myself if there is enough interest in it.