On Wed, Dec 14, 2011 at 10:19:16AM -0800, Junio C Hamano wrote: > Limiting the Porcelain layer to deal only with reasonable text encodings > (yes, I am declaring that utf16 is not among them) is perfectly fine, but > I was somehow hoping that you would allow the option for the low-level > function commit_tree() to create a commit object with binary blob in the > body part, especially after seeing the patch 1/3 to do so. > > Certainly that kind of usage would not give the binary blob literally in > "git log" output, but it is with or without the issue around NUL byte. A > custom program linked with commit.c to call commit_tree() may not be using > the data structure to store anything that is meant to be read by "git log" > to begin with. I'm happy to ignore custom programs linking against internal git code, but what should "git commit-tree" do? My gut feeling is that it should store the literal binary contents. However, I don't think this has ever been the case. Even in the initial version of commit-tree.c, we read the input line-by-line and sprintf it into place. -Peff -- To unsubscribe from this list: 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