Re: [PATCH] binary patch.

Daniel Barkalow [off-list ref] writes:

On Fri, 5 May 2006, Junio C Hamano wrote:

quoted

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.

Why do you think it makes sense to retroactively mark a blob with things 
like binariness or MIME type? To the extent that the information is not 
possible to extract from the blob contents, it seems to me to be a 
permanent aspect of the blob. And I could see having blobs with the same 
content but different type information (that one is a ZIP archive, while 
this one is a OpenDocument file), and tools may care how they were 
specified, and the user would want to be able to track how they had 
historically been marked, if the system allows them to be marked at all.

Of course, there's still the issue of how this info is generated for a new 
blob; I think it should live in the index for tracked files and come from 
a .gitignore-style file for new files. (For that matter, there could be a 
.gitmetadata file, which would handle "ignore" as well as binary and 
whatever other info you want to produce about your not-previously-tracked 
files.)

I think Nico's solution (compromise?) is the right and most
practical one.