Junio C Hamano <gitster@xxxxxxxxx> writes:
>> 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 <pclouds@xxxxxxxxx>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
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 <pclouds@xxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
--
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