This Hacker News discussion revolves around the challenges and techniques of managing modifications to upstream software projects, particularly when self-hosting or contributing to external projects. Here's a summary of the key themes:
The Problem of Managing Local Modifications
Several users expressed the frustration of needing to make small, localized changes to software projects without wanting to maintain a full fork or a "dirty" work copy. This indicates a widespread need for a more streamlined way to apply and manage these adjustments.
- "This is supercool. One my constant problem with self-hosting is that I often need to modify just a couple of files here and there, but then I'm stuck with a with a forked repo or a dirty work copy." - cyberax
Alternative Methods for Applying Changes
The discussion highlights several existing methods that users employ to achieve similar goals to the tool being discussed, such as bookmarklets, user scripts, and patching binaries.
- "For web software, bookmarklets are another great way to do that." - datadrivenangel
- "I’m a big fan of Greasemonkey scripts for this, although these days I prefer Violentmonkey because it has several capabilities that the OG doesn’t." - bartread
- "Many times I've just patched the binary even if source is available, because trying to reproduce the binary you currently have, with only the changes you want and everything else the same, can be an even more difficult exercise than simply changing a string or constant." - userbinator
Analogy to RPM Spec Files and Pristine Sources
One user drew a parallel between the described process and the way RPM spec files handle source code and patches during the build process, noting the inherent complexity of maintaining such patch sets.
- "The process described reminded me of "pristine source" and RPM spec files that take the upstream pristine source and patch it during the build process. Maintaining that is always a little bit of a headache if you don't do it regularly, especially having to maintain (generate and apply) a separate set of patch files for the changes and express/apply the patches in the spec file. This looks to make light work of that." - thwarted
The Role and Nature of Patches
There was some debate about the nature of patches and their relationship to specific commits. Generally, the understanding is that patches capture a set of changes rather than being tied to a particular commit hash.
- "Maybe I can't understand what TFA is describing, but from what I know a patch is usually tied to a specific commit, so a very specific point of time in the upstream lifetime. It does not make sense to have it lingering longer than that." - skydhash
- "A patch just encapsulates what was added and removed in a particular change, it doesn’t care about any commits." - what
Git Workflows: Rebasing vs. Merging for Patch Management
A significant portion of the discussion focused on the suitability of Git's core workflows (rebasing and merging) for managing patch sets across different versions of a project. The author of the discussed tool (Lappverk) argued that both have drawbacks for collaborative patch management.
- "When I need to maintain a fork, I just add an extra remote to git. Then I fetch upstream (what I call my remote) and rebase my changes against whatever branch I'm following. At any point in time I can generate a patch file that works for whatever version I have rebased against. Seems easy enough, I read the article multiple times and I don't get why what they are describing is needed." - doix
- "(Author here.) The difference is that git rebasing is a destructive operation, you lose track of the old version when you do it. ... Maybe that's an okay tradeoff for something you use by yourself, but it gets completely untenable when you're multiple people maintaining it together, because constantly rebasing branches completely breaks Git's collaboration model." - Nullabillity
- "(Author here.) Yeah. For reference, this is a typical patchset for the project that motivated it. [0] Some of the patches are "routine" dependency upgrades, some of them are bugfix backports, some of them are original work that we were planning to upstream but hadn't got around to yet. Some are worth keeping when upgrading to a new upstream version, some aren't. I agree that it's not ideal, but... there are always tradeoffs to manage." - Nullabillity
- "To me that sounds like not a great idea, but if you must do it, I could see some usefulness to this." - cobbzilla (referring to separate-path feature work)
- "Agreed. If you want your change and don’t want to bother the maintainers with a patch they are unlikely to accept, or can’t because it’s proprietary: fork the repo (at whatever tag makes sense), then periodically sync with the latest code for that version. The likelihood of conflicts is minimal, and often if you see conflicts it’s a good indication your issue may have been resolved. Or if not, you can see if it’s still needed, or how to adjust it." - cobbzilla
- "(Author here.) Yeah, this is the workflow that Lappverk is trying to enable. The problem is that neither of Git's collaboration models works well for this problem. Rebasing breaks collaboration (and history for the patchset itself), and merging quickly loses track of individual patches. Lappverk is an attempt to provide a safer way to collaborate over the rebase workflow." - Nullabillity
Use Cases and Trade-offs
The discussion highlights specific use cases for managing patches, such as backporting bug fixes, applying local proprietary changes, and maintaining dependency upgrades. Users acknowledge that these workflows involve trade-offs, especially in collaborative environments.
- "Some of the patches are "routine" dependency upgrades, some of them are bugfix backports, some of them are original work that we were planning to upstream but hadn't got around to yet. Some are worth keeping when upgrading to a new upstream version, some aren't." - Nullabillity
- "For example wine-staging (ran by Wine developers themselves) hosts patches for Wine project and they revise / rebase them with each Wine version, which is often not a trivial task. I don't see how you can avoid that really. But Wine staging itself is a git repository that holds patches (and their history) if that helps, which indeed can stay there for years. Same happens with patches that Debian applies on top of fixed versions of packages. They are stored in Debian's Salsa git." - shmerl