In the documentation for git notes [1] I read:

    In principle, a note is a regular Git blob, and any kind of (non-)format is 
accepted.

Then, since the empty string is a valid regular Git blob, the empty string is 
also a valid git note.

Therefore this behavior was unexpected for me:

    > git notes --ref=foo add -m ''
    Removing note for object 97b8860c071898d9e162678ea1035a8ced2f8b1f

I was surprised to see that this behavior was deliberately introduced:

    > git log -1 a0b4dfa
    commit a0b4dfa9b35a2ebac578ea5547b041bb78557238
    Author: Johan Herland <jo...@herland.net>
    Date:   Sat Feb 13 22:28:24 2010 +0100

        Teach builtin-notes to remove empty notes

        When the result of editing a note is an empty string, the associated 
note
        entry should be deleted from the notes tree.

        This allows deleting notes by invoking either "git notes -m ''" or
        "git notes -F /dev/null".

        Signed-off-by: Johan Herland <jo...@herland.net>
        Signed-off-by: Junio C Hamano <gits...@pobox.com>

I don’t understand what the motivation for this change was. Yes, it "allows 
deleting notes" by providing the empty string, but there is a specific 
subcommand for removal of a note, `git notes remove`, which makes this 
intention much clearer.

I have specific motivation for wanting to store the empty string as a git note, 
as distinct from the non-existence of a note for the object. (Specifically I 
have a tool to annotate a commit with a list of files that satisfy a certain 
condition. The empty string represents the empty list, a valid value which 
asserts that no files satisfied the condition. I can imagine many other use 
cases for which the empty string is a useful git note.)

Does anyone know why we have the existing behavior? Is it for "technical 
reasons” or was it actually considered desirable?

James Fisher 

[1]: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to