From: Nguyen Thai Ngoc Duy Date: Sat, 12 May 2012 05:20:00 GMT Subject: Re: [PATCH v2 1/4] notes: preserve object type given by "add -C" Message-ID: In-Reply-To: <7vzk9eju4m.fsf@alter.siamese.dyndns.org> On Sat, May 12, 2012 at 4:16 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy   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