Hacker News Reader

Comment by Lio | Hacker News Reader

I'd say the most interesting thing on that site is the Not-Forking idea[1].

1. https://lumosql.org/src/not-forking/doc/trunk/README.md

I got to the end of that without really understanding what this is solving, what it does, or how.

How do you handle changing upstream files locally without forking? Do you just, keep changes in a separate configuration format that is applied lazily at built time?

I've never had issues with maintaining a fork anyways.

it's a replacement for checkout + patch process.

The main advantage over plain "patch" is that it is more powerful in the face of upstream changes. For example if you rename the upstream file, you have no good way to represent this in .patch, but that project allows is. There also a way to specify patch using function name, which should make it more robust in face of upstream changes.

As for my opinion, this seems like an incremental improvement over existing tools. I'd prefer a simple shell script that does "git checkout ... && mv ... && cp .. && patch ..." over something fancy like this.

Don't we just call these out-of-tree patches? Lots of those for Linux lying about, it's not a new idea. I guess the difference is that they have multiple upstreams, so really they're more of a new project that consists of:

- A set of sqlite patches,

- Other upstreams and patches?

- A custom toolchain to build all the above together into one artefact

If a trunk is a series of patches then isn’t maintaining a series of patches against multiple upstreams just maintaining multiple forks? Feels like mostly semantics to try to differentiate at this point. I mean what is the thing that you would get from doing it this other way? Isn’t it fundamentally still going to require pulling upstream changes regularly and resolving conflicts when they occur? Reading the treatise they say “this allows us to address conflicts that normally you would have to resolve manually”. So Git has tools to pick and choose and auto resolve conflicts, you just have to customize the behavior of your tooling a bit.

Seems like they’re just ditching the inbuilt tools git/github offers to achieve this and doing the exact same thing with custom bespoke tooling. Instead of doing that, I’d be more interested in leveraging what Git has baked in with some sort of wrapper tool to perform my automation with some bespoke algorithm. There are merge drivers and strategies end users can implement themselves for this kind of power user behavior that don’t require some weird reinvention of concepts already built into Git

Article doesn't tell me why it's better than git's subtree merge.

let's say you need to copy config.h.in to config.h and patch a few lines. In case of "subtree merge", you will have to do it manually, every time you upgrade upstream.

I'm confused, is this just patch and apply patch?

Yes. It's a small DSL to fork a repository and apply a series of textfile transformations (replace file, replace partial file).

But if you give this a cool name, it's a New Idea.

So it's a fork but with somewhat semantic diff specifications?

Yes, specifications which could almost certainly be applied with a custom merge drivers or strategy rather than trying to come up with a clever name and hand baking a custom toolchain to do what you can already do with Git

Not all projects use git.

How many of those projects are attempts at maintaining patches across multiple upstreams, where none of those upstream projects use Git? The author freely admits in their post that all upstream projects in their case are using git, like most of the FOSS world. They just chose fossil for their downstream project because Reasons.

Weird.

The TeX source works like this, too. There is the original tex.web and some change files which get applied when converting it to either a TeX document or pascal source. (These days the pascal is further translated to C.)

did you say "fork"?

I have never seen PikChr diagrams before, very interesting.

https://pikchr.org/home/doc/trunk/homepage.md

Made by the same people who brought us SQLite.

The US Navy?

I was going to say that.

We really need a way to customise software at the source code level without forking.

You mean like #define + #ifdef?

Very niche but: https://github.com/SpongePowered/Mixin

It's not really possible to implement in the same way for many other languages, but something like this but for source code transformations (rather than bytecode, or machine code for compiled languages) is probably the kind of thing they're thinking of.

Mixin allows you to insert code into methods, modify calls to functions, read/write to local variables, modify constants, and a lot more in that type of vein. It is the way mods are made in the Fabric mod loader for Minecraft. I believe Forge also reluctantly added support for Mixin back in 1.16 or so.

Back in the day I used AspectJ to do something like this. The interface was decently friendly and IMO decorator style patterns are going to be the most user friendly approach to something like this. You won’t ever find a universal solution to this though without doing transpilation to some common format that gets morphed (ASM in your example, but I could see also a theoretical world where WASM would offer this)

AFAIU, it's a build strategy.

Instead of having a fork, you have a configuration that says "checkout x then apply changes a,b,c".

Reply on news.ycombinator.com