Git commit content

[Ben Cooksley]

On Mon, Aug 29, 2022 at 6:24 PM Helio Chissini de Castro <helio at kde.org>
wrote:

> Honest question
>

Hey Helio,


>
> Since these files are generated, and create huge hurdles to commit, was
> not make sense to generate this on build time and avoid such huge commits ?
>
> Or we have a technical block that maybe we can help to solve ?
>

These files have usually been the result of generation processes in either
our own repositories (develop.kde.org), or from other external datasets
(kstars).
As such they're not really suitable to generate at build time.


>
>
> []'s
>
>
Cheers,
Ben


> On Sun, Aug 28, 2022 at 1:17 PM Ben Cooksley <bcooksley at kde.org> wrote:
>
>> Hi all,
>>
>> Over the past couple of months we have had several incidents where people
>> have needed/attempted to push large text files into KDE Git repositories.
>>
>> While this does not seem immediately problematic, it is something that
>> unfortunately the email sending components of our Git hooks are unable to
>> handle (likely due to them embedding commit diffs into the body of emails).
>>
>> This results in them consuming an entire CPU core of the server until
>> Gitlab times out on them and kills them (failing the push/merge in the
>> process).
>>
>> For the most part these have been programmatically generated data
>> sources, making the diffs of little use.
>>
>> Where possible it is recommended not to commit these sort of artifacts to
>> KDE Git repositories, but where it is not avoidable please ensure that:
>> a) The data is not all on a single line (JSON pretty print where
>> possible);
>> b) That the file has been flagged as binary data using .gitattributes
>>
>> This should assist the email generating components of the hooks in more
>> easily handling the content.
>>
>> Thanks,
>> Ben
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20220829/c6b058c1/attachment.htm>