* Fabio Valentini: > In the rare occasion that I need to make downstream-only changes with > patches, I usually just explode the upstream tarball, run "git init", > then "git add .", "git commit -m import", apply my changes, and then > do "git diff --patch > ../00-my-changes.patch" (if it's just one > commit), or "git format-patch -o ../" if there are multiple commits, > and then delete the exploded sources again. That's what we do for glibc, too. In Fedora, we do not have that many patches, but we do in downstream. Like so many of us, I wrote some fairly elaborate scripts for that: <https://pagure.io/glibc-maintainer-scripts> Carlos wrote some documentation for them: <https://fedoraproject.org/wiki/GlibcRawhideSync> However, they still require training in an unusual process, and there are corner cases which are difficult to fix. Most of that would just go away if the generated Git tree where the primary artifact developers worked with. There would still be corner cases (especially if dist-git were kept in the background), but I expect that they would not interrupt developer workflow (unlike with the non-authoritative, on the fly repository). They could still produce their patches, submit merge requests, and get reviews and (CI) test results that way. The dist-git update (with a potential merge first in the other direction) would have to be handled by people experienced with that process, though. But for large packages with a lot of backporting activity, that might be fine. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
