You may have a look at Quilt. I doesn't solve the problem the author described but may help you once you accept there is no easy solution in sight.

Quilt is automation for the "bag of patches" model. I used it once when I needed to upgrade the internal bag of patches at $big_corp so as to apply them to a newer version of $public_app. It was predictably complex but somehow still manageable.

If you squint a bit then the [bag of patches] + [automated application in order] is a poor man's Git. If you keep this in a git repo then you're basically versioning repos (poor man's ones) in a repo. It almost sounds like the solution to author's problem :)

▲

Nullabillity 3 days ago | parent | next [-]

Yeah, I mentioned Quilt in the post! Lappverk is effectively an exercise in "What if Quilt, but you could interact with it using any Git tooling, rather than Quilt's half-baked custom VCS?".

▲

pc486 3 days ago | parent [-]

Have you seen git-spice? It may be up your alley.

https://github.com/abhinav/git-spice

▲

Nullabillity 3 days ago | parent [-]

I haven't, no. But as far as I can tell from the documentation, it looks more like an alternative to stgit (with a similar lack of history or collaboration support)?

	▲	pc486 2 days ago \| parent [-]
		stgit is similar in that it sits with git, but it's not the same workflow. git-spice has branches per feature that base on one-another. It's more git-like than quilt-like. What you get is git-styled patch-series development. Branches on branches where each branch maintains history of the feature. A git-spice workflow is compatible with GitHub style PRs where a PR depends depends on another PR. Or pair git-spice with format-patch you can share with developers who prefer patch files. Or take patches from someone and import each patch as a branch, then let git-spice track the stack position.

▲

graynk 3 days ago | parent | prev | next [-]

It's mentioned in the article

▲

actionfromafar 4 days ago | parent | prev [-]

quilt is really cool