Re: RFC: marking spam via refs/notes/spam to hide it

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Thu, Jun 27, 2019 at 06:52:36PM +0000, Eric Wong wrote:
>> I'm reluctant to delete spam because it rebases the repository -- for 
>> large
>> ones this can cause excessive downloads to mirrors. A thought occurred to me
>> -- would it make sense to just hide spam from the frontend? E.g.:
>>
>> public-inbox-hide linux-kernel message@id
>>
>> This would do the following:
>>
>> - remove that message from search databases
>> - attach a refs/notes/spam git-note to that commit
>> - tell public-inbox-init/reindex to ignore this commit in the future
>
>Aside from the git note, public-inbox-learn already does that:
>
>   public-inbox-learn spam </path/to/message
>
>   (scans everything in ~/.public-inbox/config since spam is
>   frequently cross-posted)

Ah, that shows how carefully I read docs, I guess. :) Is it possible to 
just specify a message-id, so that there's no extra step to dump the 
spam message into a file?

>> Seems like it would be easy to do and would give a way to remove spam
>> without needing to edit git history.
>
>It appends to git history, v2 changes the 'm' file to a 'd'
>file with the corresponding blob; v1 removes the file from the
>tree.  It doesn't add blobs to git history, but there'll be
>new tree and commit objects.  There's no rebasing at all.
>
>public-inbox-index has always handled unindexing it in mirrors,
>too.

Right on, thanks! This is certainly along the same lines that I was 
thinking.

-K