Re: [PATCH] binary patch.

From: Junio C Hamano <junkio@cox.net>
Date: May 5, 2006, 19:23 UTC
Message-ID: <7vac9wxom0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0605051431390.24505@localhost.localdomain>

Nicolas Pitre <nico@cam.org> writes:

Show 11 quoted lines

> On Fri, 5 May 2006, Junio C Hamano wrote:
>
>> The delta is going to be deflated and hopefully gets a bit
>> smaller, so if we really care that level of detail, it might be
>> worth to do (deflate_size*3/2) or something like that here, use
>> delta with or without deflate whichever is smaller, and mark the
>> uncompressed delta with a different tag ("uncompressed delta"?).
>> And for symmetry, to deal with uncompressible data, we may want
>> to have "uncompressed literal" as well.
>
> Nah...  Please just forget that.  ;-)

I was serious about the above actually.

BTW, this "binary patch" opens a different can of worms.

Currently, the diff uses a heuristic borrowed from GNU diff (I did not look at the code when I did it, but it is described in its documentation) to decide if a file is binary (look at the first few bytes and find NUL). I am sure people will want to have a way to say "that heuristic fails but this _is_ a binary file and please treat it as such".

There are two, both valid, I think, ways to do it.

 - give an option to "diff" that says "treat this path as binary
   for this invocation of the program".

 - give an attribute to blob object that says "this blob is
   binary and should be treated as such".

The latter is probably the right way to go in the longer term.

A blob being binary or not is a property of the content and does not depend on where it sits in the history, so unlike "recording renames as a hint in commit objects", the attribute is at the blob level, not at the commit nor the tree that points at the blob.

But "binaryness" affects only certain operations that extract the data (e.g. diff and grep) and not others (e.g. fetch). Also, it makes sense to being able to retroactively mark a blob, which was not marked as such originally, is a binary. So I do not think it should be recorded in the object header.

Which suggests that we may perhaps want to have notes that can be attached to existing objects to augment them without changing the contents of the data, and have tools notice these notes when they are available. Another example is to associate correct MIME types to blobs so, gitweb _blob_ links can do sensible things to them.

These external notes are purely for Porcelains (in the context of this sentence "diff" and "grep" are Porcelain), but we would also want a way to propagate them across repositories somehow. In a sense, "grafts" information is similar to the external notes in that it augments existing commit objects, but its effect is a bit more intrusive; it affects the way the core operates.