5 ms·

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 https://lumosql.org/src/

by Lio 1y ago

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 https://lumosql.org/src/not-forking/doc/trunk/README.md

actionfromafar 1y ago
I have never seen PikChr diagrams before, very interesting.
- sksrbWgbfK 1y ago
  https://pikchr.org/home/doc/trunk/homepage.md https://pikchr.org/home/doc/trunk/homepage.md Made by the same people who brought us SQLite.
  - stonemetal12 1y ago
    The US Navy?
aredox 1y ago
I was going to say that. We really need a way to customise software at the source code level without forking.
- Arwill 1y ago
  You mean like #define + #ifdef?
  - LoganDark 1y ago
    Very niche but: https://github.com/SpongePowered/Mixin 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.
    - SOLAR_FIELDS 1y ago
      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)
eddd-ddde 1y ago
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.
- theamk 1y ago
  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.
90s_dev 1y ago
I'm confused, is this just patch and apply patch?
- alexjurkiewicz 1y ago
  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.
  - worldsayshi 1y ago
    So it's a fork but with somewhat semantic diff specifications?
    - SOLAR_FIELDS 1y ago
      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
      - SoftTalker 1y ago
        Not all projects use git.
        90s_dev 1y ago
        Weird.
        SOLAR_FIELDS 1y ago
        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.
  - 1y ago
aidenn0 1y ago
Article doesn't tell me why it's better than git's subtree merge.
- theamk 1y ago
  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.
e63f67dd-065b 1y ago
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
- SOLAR_FIELDS 1y ago
  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
riffraff 1y ago
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".

by Lio 1y ago

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 https://lumosql.org/src/not-forking/doc/trunk/README.md

actionfromafar 1y ago

I have never seen PikChr diagrams before, very interesting.

sksrbWgbfK 1y ago
https://pikchr.org/home/doc/trunk/homepage.md https://pikchr.org/home/doc/trunk/homepage.md Made by the same people who brought us SQLite.
- stonemetal12 1y ago
  The US Navy?

aredox 1y ago

I was going to say that. We really need a way to customise software at the source code level without forking.

Arwill 1y ago
You mean like #define + #ifdef?
- LoganDark 1y ago
  Very niche but: https://github.com/SpongePowered/Mixin 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.
  - SOLAR_FIELDS 1y ago
    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)

eddd-ddde 1y ago

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.

theamk 1y ago
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.

90s_dev 1y ago

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

alexjurkiewicz 1y ago
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.
- worldsayshi 1y ago
  So it's a fork but with somewhat semantic diff specifications?
  - SOLAR_FIELDS 1y ago
    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
    - SoftTalker 1y ago
      Not all projects use git.
      - 90s_dev 1y ago
        Weird.
      - SOLAR_FIELDS 1y ago
        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.
- 1y ago

aidenn0 1y ago

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

theamk 1y ago
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.

e63f67dd-065b 1y ago

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

SOLAR_FIELDS 1y ago
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

riffraff 1y ago

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".