Re: [PATCHv3 3/5] builtin/notes: Add --allow-empty, to allow storing empty notes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 7, 2014 at 7:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Johan Herland <johan@xxxxxxxxxxx> 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@xxxxxxxxxxx>
www.herland.net
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]