[PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set

[Jacob Bachmeyer]

On 10/1/25 10:57, Jussi Kivilinna wrote:
> On 01/10/2025 04:26, Jacob Bachmeyer via Gcrypt-devel wrote:
>> On 9/30/25 01:30, Jussi Kivilinna wrote:
>>> Hello,
>>>
>>> On 27/09/2025 10:54, Jussi Kivilinna wrote:
>>>> * cipher/mceliece6688128f-patches: New.
>>>> * cipher/mceliece6688128f.sh: Apply patches from
>>>> 'cipher/mceliece6688128f-patches/*'.
>>>> -- 
>>>
>>> I had to drop this commit with patch files as git server rejects 
>>> this with:
>>>
>>> remote: 
>>> cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:40: 
>>> trailing whitespace.
>>> remote: +
>>> remote: 
>>> cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:44: 
>>> trailing whitespace.
>>> remote: +
>>> remote: 
>>> cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:49: 
>>> trailing whitespace.
>>> remote: +
>>> <...snip...>
>>> remote: error: hook declined to update refs/heads/master
>>>
>>> Should I anyway try to wrestle this change in to repo? These patch 
>>> files could be packaged into tar.gz for example.
>>
>> Could the patch be fixed to remove the trailing whitespace?  I 
>> suggest trying Emacs M-x whitespace-cleanup on the patches.
>>
>> At a quick check, it looks like that hook may have legitimately 
>> caught patches that add non-empty blank lines.  Is there some reason 
>> unknown to me to have whitespace on seemingly blank lines in C code?
>>
>
> Problem with diff/patch files and whitespace is that these are machine 
> generated text files. In diff format, unedited lines start with one 
> space character. Empty unedited lines are represented by lines with 
> single space character. Pre-commit hook detects these as text files 
> with single space lines and rejects commit.

Now I see what is happening:  the commit itself contains a diff, and I 
misread it embedded in `git diff`.

> Either hook would need to be changed to support patch/diff files or 
> diff files be hidden somehow from hook (for example in gz). Latter 
> seems worst of these as that hides changes from trivial git code review.

Would it be feasible to carry the mceliece code on a tracking branch in 
the repository, rebase the patchset when pulling updates to an 
intermediate branch, and merge from that intermediate branch instead of 
carrying the code directly?

You would have one branch carrying only pristine upstream sources 
(perhaps itself pulled using Git if the code is managed in Git 
upstream), one branch carrying patched sources that is rebased as 
upstream updates are imported and merged to the mainline branch. Then 
you would manage the changes in Git instead of using a script to apply them.


-- Jacob