Chromatic | Embedded/Firmware Engineer | New York City (NYC) | Full Time | https://www.gochromatic.com/

We are a small team and are building something new and exciting in the medical device space.

Skills we are looking for: ARM, RISC-V architectures, embedded C, Rust, freeRTOS, BLE, I2C, SPI, UART, I2S, PCB bringup and debugging; familiarity with Python and Bazel is a plus.

Please email me directly: seb+hn [AT] gochromatic [DOT] com

Yes I think for git users there are a number of great gui and tui and cli tools to simplify workflows. Here is a good list: https://github.com/dictcp/awesome-git?tab=readme-ov-file#cli...

I think fossil is not exactly post-git but runs in parallel with git. But definitely a good fit for small teams. For true post-git if you feel adventurous I would try jj or pijul.

I would consider CVS and RCS worth studying for historical reasons, since they have no releases for over a decade (according to Wikipedia). I was considering incorporating the history of version control, but there is already a great one here: https://blog.plasticscm.com/2010/11/version-control-timeline... -- it has a great comment section as well. Maybe it would be interesting to create an updated version of the article.

As for "$Id$", in bazel you would use https://bazel.build/docs/user-manual#workspace-status which works very well and can differentiate between stable and volatile.

That is indeed somewhat ironic. It does not seem particularly active, with the last and the last release more than 1 year ago.

Is there a design doc one could study? At a high level I understand how the fact that patches are commutative is elegant, but it seems to me there are performance impacts when, to get to a repository state, we have to apply many patches. Would love to read how pijul thinks about that.

This is indeed one of the issues of Pijul, but patch application is extremely fast, which makes it easy in the vast majority of cases (we don't apply patches to files directly, but to an on-purpose on-disk datastructure).

We also have a tag features, allowing you to pinpoint versions and go back instantly, and we have plans to make that feature even lighter on disk space.

Microchip Fabricarion has its flaws but gives a good high level overview includinh bringing, test and packaging: https://www.goodreads.com/book/show/1203098.Microchip_Fabric...

Thanks for sharing - that is too bad. Is there nothing in the way-back machine? Or maybe somebody has a local copy?

Sadly not, as far as I know :/ So unbelievably much knowledge vanished... god bless the internet archive for all such losses they have prevented.

Super-cool. I love this one: https://source.puri.sm/Librem5/linux-next/-/issues/44#note_1...

That sounds so cool. Maybe collect the in a directory (like I did) and ask for permission to publish them after some time when the content might not be relevant any longer?