Programming

Just two nitpicks:

1. On the blog article

I gave the tutorial a quick look, but it didn't showcase any real benefits for my workflow. It confirmed my bias: this was for people who were afraid of Git's power, not for those who had already mastered it.

Well, it is the tutorial by Steve Klabnik, one of the co-authors of one of the two best and most comprehensive books on Rust. And as I anticipated because of that, it is a concise and lucid write-up and probably for everyone who enjoys good technical writing a refreshing read.

2. On jujutsu

I have been trying it both at home, and at work, for some months and it worked very well for me (for work I was using 'stealth mode', nobody was knowing I was using jujutsu).

It is in fact simpler and at the same time more powerful. The only area where I had hickups is pushing to a git repo:

• When the repo has more complex access modes, like ssh + vpn + git://..., it is better to use git directly. In new versions of jujutsu, this is built-in.

• When one works on several machines in parallel (my typical use case here is couch-testing something on my laptop after the day), the git repo does not contain the on-going jujutsu changes. This leads to either conflicted changes or one has to do regular git force pushes. When I think about it, it is possibly better to just rsync the jujutsu repo (jujutsu does support that because it version-controls the metadata, one however has to be careful not to create backup copies of git metadata).

• Also, jujutsu will readily change private history. As a counterbalance it has some configuration settings which protect public history from changing - the defaults are good but the settings still might be worth to have a look at.

Of course, Torvalds' essential rules on public and private history still apply. (see also this article by Jonathan Corbet on rebase/ merge flows which is, I think, really good advice for larger orgs).