Not really apples to apples. iOverlay is more like a topology toolkit - things like set operations and buffering. pretty different from triangulation.

The commenter probably meant https://github.com/iShape-Rust/iTriangle, a sibling library that is indeed quite fast at triangulation, especially on bigger inputs

Thanks, I didn’t know about that one!

In the meantime, you can check out maps.earth, which has bike+transit directions for the puget sound area (also sfbay, los angeles, portland)

...though the elevation model I'm currently using is courser (~30m, from Mapzen skadi). This is a good reminder to fix that where available!

Hit me up if you want to use the iOS beta which has some nice transit features (already available on the web).

Nice! I’m always exciting to try a new non-car centric mapping/routing app.

In my experience, Google Maps too often sends me down dangerous streets - busy, wide, arterials with fast moving automobiles.

Though I do know some people who prefer them because they can be a little faster. Not worth it for me. I'd much rather go a little out of my way for a comfortable safe ride.

If you’re into this, and ever in Seattle check out the connections museum.

https://www.telcomhistory.org/ConnectionsSeattle.html

The volunteers there maintain a bunch of functioning cool vintage equipment you can see in action and even use.

Be sure to send them an email first, so that you can arrive at the proper time for them to give you a tour. It is very, very worth it. One of the best museum experiences so far.

Thanks to both of you for the info. I'm longtime Seattle and I had no idea. I'm still disappointed that the living computer museum was closed. Jody Allen is a decent person so was surprised she let that tiny line item expire from the spreadsheet, I digress.

+1 to this! If you have any interest in telephones, telephone switching, or phreaking, this place is incredible. And the people who run it are awesome.

A branch is mutable and holds only one version of history at a time.

If you never rewrite history, you could achieve something similar, but it precludes you from having a “tidy” branch.

Whether or not you’re into rewriting history is a different discussion that has been hashed out over and over again.

Another thing that becomes easier with change IDs is reviewing multiple related commits together, essentially "stacked pull requests".

If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.

I heard that the github CLI recently introduced support for this, but since in git there's no concept of dependent branches (a branch isn't even an object in git, just a reference to a commit), I think this approach will always be clunkier than reviewing commits related by a change ID.

> If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.