Git linear history is a recommendation to disguise the real reasons for change for code, and to lie about the true history of the code.
All of the commits on `main` should be signed merges.
All commits on `main` are production code.
#HillToDieOn
A small snippet of code to mark up source code for transclusion into a presentation, and an example project that builds a (micro-tiny) C++ library, tests it, and generates an html page with snippets of code using emacs.
May it be of some use.
https://github.com/steve-downey/surround
#emacs #orgmode
GitHub - steve-downey/surround: Surround Source Code for org-transclusion
Surround Source Code for org-transclusion. Contribute to steve-downey/surround development by creating an account on GitHub.
Duh.
If you want to be able to push a `git subtree` back upstream, you can't squash the pull into your repo.
Obvious, now.
Still better than `git submodule`.
LAN Party in my hotel room!
But this sounds very much like an affine type, and normally linear.
The same sort of type system the Rust borrow checker uses.
I suspect this is why structured concurrency works so well.
A new idea *for me* that I'm working out about the new sender receiver model in C++26.
It's based on chaining function calls, and the call itself is an operational state, including the return value. By construction operational states are constructed exactly once (it's an object) and are completed exactly once in one of three ways, value, error, or by stopping when asked to cancel. Or one might never, because it infinite loops, I suppose.
Note to self: laptop charges much faster when all the cables and bricks are plugged in.
At the C++ Standard meeting in Croydon.
No live tooting permitted.
News to be reported next Saturday.
Anna Spanner 👩🏫🇪🇺🧪