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`.
@DanielaKEngertFor another 10 days. Week in London visiting my Group there, and now some personal time up near Edinburgh.
@dhry
Mobile office may be slightly overprovisioned.
Still thinking about a mobile gitlab and NAS, though.
Travel wifi router is such a simplification, just one thing to get on the Internet and then everything is. Can even run VPN on it.
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.
Anna Spanner 👩🏫🇪🇺🧪