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

[Jacob Bachmeyer]

On 10/5/25 04:57, Jussi Kivilinna wrote:
> Hello,
>
> On 02/10/2025 02:31, Jacob Bachmeyer via Gcrypt-devel wrote:
>>
>> 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.
>>
>
> That seems a bit more complicated than this in my opinion should be. 
> We already have changes in git history and duplicating that history in 
> shadow branch seems extra work. How about if generator script extracts 
> changes to 'mceliece6688128f.c' from active branch and then apply 
> those patches. So we'd have something like this:
>
> [...]

This would essentially reimplement `git rebase` except without keeping 
the clear records that a shadow branch scheme would carry.  With the 
shadow branches I propose, each merge into mainline would have exactly 
the changes made to adapt the upstream sources to libgcrypt, greatly 
facilitating auditing.

Unfortunately, it turns out that Git does not actually support the 
regular merges required in my proposal, so it all falls apart.  :-(


-- Jacob