Modifying other people's software

Summary

Every once in a while, we all feel the need to modify something that someone else built. Sometimes those patches make sense to upstream, but not always. Sometimes they need a bit more time to bake, before they're ready to share with the world. Sometimes they're too specific to your environment. Sometimes it's just some personal preference, that the upstream wouldn't want to force upon everyone. And sometimes, just sometimes, you just want to run it yourself now, before it has had the time to make it through the whole review gauntlet. Hey. Just a heads up, this is a (very) long-winded announcement for a new project of mine, Lappverk. The rest of the post will provide some background on the hows and whys, and I'd recommend sticking around for that. But you can always jump straight over there, if you'd like. I won't hold you. This is easy enough, right? These days, pretty much every project uses Git. It is, famously, a DVCS. A Distributed Version Control System. Distributed. It's right there in the acronym. That means that it can work without any central repository. You can just clone anything you want, and commit whatever changes you want. You can make your own new central repository, and push your changes to there... original project be damned! Hell, most Git hosts have an easy-to-use button to do just that: "Fork"! So... that's the dream, right? Just use Git for what it's good at? Right? Right? One tiny catch... Git really wants history to roll forward. You commit a change, and then you make another commit that builds on that. You never change an existing commit, you just add new commits with the further changes. Or, well. You can change a commit, but Git doesn't have any way to relate the two commits. It just sees two entirely different timelines, and gets very confused if they ever end up mixing. There's a reason that "Never rewrite public branches" is a very common mantra. And that works when you're working on a (relatively) static foundation. When you're working...