Re: [PATCH 3/3] Do not create commits whose message contains NUL

Junio C Hamano [off-list ref] writes:

quoted

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.

Yeah, you are right. Perhaps we should tweak updated 3/3 to check at the
lower level commit_tree() then.

I've rewrote the log message for 2/3 as follows so we can go either way
;-)

s/rewrote/rewritten/ obviously...

    Convert commit_tree() to take strbuf as message
    
    There wan't a way for commit_tree() to notice if the message the caller
    prepared contained a NUL byte, as it did not take the length of the
    message as a parameter. Use a pointer to a strbuf instead, so that we can
    either choose to allow low-level plumbing commands to make commits
    that contain NUL byte in its message, or forbid NUL everywhere by
    adding the check in commit_tree(), in later patches.
    
    Signed-off-by: Nguyễn Thái Ngọc Duy [off-list ref]
    Signed-off-by: Junio C Hamano [off-list ref]

And 3/3 looks like this:

    commit_tree(): refuse commit messages that contain NULs
    
    Current implementation sees NUL as terminator. If users give a message
    with NUL byte in it (e.g. editor set to save as UTF-16), the new commit
    message will have NULs. However following operations (displaying or
    amending a commit for example) will not keep anything after the first NUL.
    
    Stop user right when they do this. If NUL is added by mistake, they have
    their chance to fix. Otherwise, log messages will no longer be text "git
    log" and friends would grok.
    
    Signed-off-by: Nguyễn Thái Ngọc Duy [off-list ref]
    Signed-off-by: Junio C Hamano [off-list ref]