On Fri, 5 May 2006, Junio C Hamano wrote: > 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.) -Daniel *This .sig left intentionally blank* - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html