From: Johan Herland <johan@herland.net>
Date: Sun, 09 Nov 2014 12:31:32 GMT
Subject: Re: [PATCHv3 3/5] builtin/notes: Add --allow-empty, to allow storing empty notes
Message-ID: <CALKQrgdFDHUc8JzH3XnwvnHdEZOhUN=EmrWXKKDLd+6MG7jMKw@mail.gmail.com>
In-Reply-To: <xmqq1tpehopp.fsf@gitster.dls.corp.google.com>

On Fri, Nov 7, 2014 at 7:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:

[...]

> Assuming that it is a good idea to "allow" empty notes, I think
> there are two issues involved here:
>
>  * Traditionally, feeding an empty note is taken as a request to
>    remove an existing note.  Therefore, there is no way to
>    explicitly ask an empty note to be stored for a commit.
>
>  * Because feeding an empty note was the way to request removal,
>    even though "git notes remove" is there, it is underused.
>
> In other words, assuming that it is a good idea to allow empty
> notes, isn't the desired endgame, after compatibility transition
> period, that "git notes add" will never remove notes?
>
> With that endgame in mind, shouldn't the internal implementation be
> moving in a direction where "create_note()" will *not* be doing any
> removal, and its caller (i.e. "add") does the switching depending on
> the "do we take emptyness as a request to remove"?  I.e.
>
>          static int add(...)
>          {
>                 if (!allow_empty && message_is_empty())
>                         remove_note();
>                 else
>                         create_note();
>         }
>
>>  static void create_note(const unsigned char *object, struct msg_arg *msg,
>> -                     int append_only, const unsigned char *prev,
>> -                     unsigned char *result)
>> +                     int append_only, int allow_empty,
>> +                     const unsigned char *prev, unsigned char *result)
>
> In other words, I have this suspicion that create_note() that
> removes is a wrong interface in the first place, and giving it
> a new allow_empty parameter to conditionally perform removal is
> making it worse.  No?

I agree, and it's fixed in the re-roll. It turned into a slightly
larger rewrite than anticipated, but I'm fairly happy with the result.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net