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
_______________________________________________
Gcrypt-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
