Just started a discussing a solution I came with at work: "I know I might sound like a rambling mad man, just bear with few minutes. Okay ? Good ... Did you know that git submodules can be recursive? So you can have an earlier commit of the same repo as submodule in the current head..."

@ln I actually used that in some demo code.
It's go code so you can make go map an arbitrary import path to the submodule.
The discussion was about supporting older file formats.
So the parser for v1.0.3 contained the parser for v1.0.2 as submodule which was mapped to "" so the ReadFile of v1.0.3 could just fall back to ReadFile of v1.0.2 if it encountered an old format. Since v1.0.2 contains v1.0.1 as a submodule it can then fall back to v1.0.1 ... you get the idea?

@ln Of course ReadFile v1.0.3 would need some way to convert the output of v1.0.2 to current format, but migrations between two version are solvable problem.

Not sure if my colleagues are impressed or afraid.

@sebastian hmm, that's actually kinda valid, beats publishing the code or setting up a registry to serve tagged versions.

You could also do some trickery to make go get work with the internal gitlab and tag versions there.
Slightly less cursed.

In the end we agreed on a slightly different solution, removing the need to have anything recursive.

@sebastian @ln once you find a security issue in an older version, you'll enjoy it even more! ;)

@strangeglyph Think about it. The endless possibilities. You can thank me later.

@sebastian @strangeglyph

gitcoin proof of work: produce a commit that includes itself as a submodule

@dhivael @strangeglyph Thought about ways to achieve that. Then put it on the gitlab. Call it documentation. Tell the new guy to check it out ...

Sign in to participate in the conversation – a Fediverse instance for & by the Chaos community