On Sat, May 12, 2012 at 4:16 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> _Automatically_ converting a non-blob object to a blob is >> wrong. Either this way, or reject non-blob objects upfront. > > But wouldn't it be even _more_ wrong to stuff a non-blob object at the > leaf level of the notes tree? If people deliberately want to do that and notes subsystem knows not to mess with non-blob objects, I think it's ok. Though if users want to add some text, but put non-blob by mistake, then it's wrong to accept it. > It is not automatically "converting"; as far as the notes subsystem is > concerned, the data you throw at it to be associated with an object the > note annotates has always been uninterpreted stream of bytes. If an > application wants to store the raw representation of a commit object > including the log message and its header, it has every right to expect > that it can use "git cat-file commit $argument_to_the_C_option" as the > source of that uninterpreted stream of bytes, doesn't it? Some part of git-notes expects this stream of bytes to be textual, human readable. In that case, "git notes add -C commit/tag"'s stuffing a blob with the given commit/tag content to notes tree may make sense. Personally I'd rather stuff the commit/tag object instead so no new blobs are created. The end result is the same: read_sha1_file() always return correct text, so does "git notes show". The difference after this series is "notes add -C commit; notes append -m foo" now results in an error message while it case goes smoothly without the series. Perhaps we can be more flexible here on appending and allow to append non-tree objects to non-tree objects, resulting in a blob note. -- Duy -- 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