The original study was flawed I’m afraid https://news.ycombinator.com/item?id=41091803

Someone always brings that up. I guess you couldn't help it?

pre-commit hooks are awful, they get in the way of interactive rebasing. pre-push is where they belong; save a round-trip through CI.

You can check inside the hook if you're in the middle of the rebase, and exit the hook early.

This is what we have in our hooks:

    if [ -d "$(git rev-parse --git-path rebase-merge)" ] || \
       [ -d "$(git rev-parse --git-path rebase-apply)" ] || \
       [ -f "$(git rev-parse --git-path MERGE_HEAD)" ]; then
        exit 0
    fi

Thanks for this, I can’t believe this never occurred to me to try to do.

I would argue that if the pre-commit hooks come in the way of rebasing, either the commit hooks are doing way too much (which is one of the points of the article) or you are creating broken commits during rebasing. If any of the commits you are rebasing is e.g. breaking formatting rules, they shouldn't have been committed that way in the first place.

I personally avoid pre-commit hooks and instead use git rebase -x "hook" to ensure my commits are not broken

I love hooks in general but I definitely have a thing against hooks that aren't read-only (except maybe some autogenerated stuff that "can't go wrong").

The hooks can fail my commit all they want, but I don't want them actually changing anything I've done, which definitely implies no reformatting in hooks.

maybe, because i really don't have the problem you're describing.

yes, formatters run on every commit. not only during rebase, but also every commit beforehand. if that is done consistently, the formatter does not cause merge conflicts.

merge conflicts during rebases due to variable name changes occur without commit hooks, too.

> if you have a hook that is designed to introduce said white changes at each commit of a rebase them you are going to have frequent merge conflicts.

Only if you rebase commits prior to the introduction of the hook. Otherwise that whitespace change should be already there in the old commits.

Yeah there's really no trouble with a pre-push hook that runs common/fast code checks. For TS projects I just run formatting, type, and lint checks. Faster feedback than spinning up a runner in CI and if I don't need it I just tack on --no-verify.

> For TS projects I just run formatting, type, and lint checks.

For formatting I find that it's clearly preferable to lean on the IDE and apply the source code formatter at each file save, and apply it only to the file you are touching. Type checks should be performed right before running unit tests, for the same reason unit tests are executed.

Yeah of course, same here for formatting. But in the world of LLM agents it's pretty easy to have formatting issues sneak by without the IDE being involved. It's a very quick and easy check.

For type checking, I guess that makes sense if your unit tests are small and quick. At work type checking our entire codebase can take like 10-15 seconds with a cold cache, but running all unit tests takes 20 minutes (and multiple shards in CI). Seems like a no brainer to just run the cheap one more often.

Database integrity constraints fall into the same category.

This entire class of automation is awful and defeats the robustness of the tool itself.

All of these things have terribly unpredictable consequences and tend to fail at the worst moments, such as during a SEV.

You can encode the same rules and discipline in other ways that do not impact the health of the system, the quality of the data, or the ability of engineers to do work.

agents trip up over them too.

I want this for pedestrians and cyclists at intersections, and particularly HAWK beacons.

https://www.roundabout.tech/ tackles this problem

I’d highly recommend looking up “Situational leadership” if you’re worried about coming off as micro-managing. You need to adapt how you’re mentoring based on the mentees skill and confidence.

That makes sense. In this situation it was a bit tricky as I didn't actually know the developer at all (different team), but I should have picked up on it.

I’d say Matt O’Dowd of PBS Space Time is the closest to Levine’s role?

Gotta love the confidence to casually think every physicist for the past 100 years is an idiot.

One of the best commencement speeches I’ve seen.

A couple of little Apple Watch apps - a drinks counter that calculates approx BAC, and a timer for stretching that gives a 5s pause between stretches.

Coupling / decoupling at high frequencies would be a challenge for sure - but seems achievable in a world of fully autonomous vehicles that can communicate.

Right now to ensure absolute safety trains are mechanically coupled, which can't be done while moving, and takes a few minutes to do safely.

I believe most AV convoys propose virtual coupling to get around this, but the failure scenario where something in the convoy comes to a sudden stop and the other things in the convoy don't, is pretty gnarly. Modern trains have a bunch of mandated safety measures in their mechanical coupling to prevent nasty things like jackknifing, or even worse, telescoping https://en.wikipedia.org/wiki/Telescoping_(rail_cars)

This is speculation but I wonder if you could have cars couple with "cat whiskers" that are mechanical but not load bearing. so you don't need to rely on wireless comms for coordination

I’m not sure what load bearing means in this context.

Generally speaking mechanical coupling takes a while because you really, really do not want an errant car to detach during its journey. In the worst possible case scenario, a rear carriage has decoupled from a train and then the following one has crashed into said carriage. https://localtvkstu.wordpress.com/2013/11/05/crews-respond-t...

I don’t think the second part (about length of the train) is accurate at all. Yes, a train made of pods roughly car sized would be longer, but only roughly 3x. If you look at the duty cycle of say BART rail, you could fit a lot more than 3x trains on it. The rail is empty most of the time.

In a rail network you are only as good as your most congested pipe. BART is a pretty good example of this, because while the outer legs are relatively infrequent, they all converge on the Transbay tube at a combined 2.5 minute frequency, which is about the safe braking distance with some buffer for a train of that size and weight. Longer convoys would require even more braking distance, and already trains cannot rely on the AV technologies of cars because the braking distance is beyond line of sight.

You could run more trains only between the suburban branches but there isn't a whole lot of demand for that.