Thanks for the feedback! The reason I like having the duplicate change as the working copy and squashing it down into the review change is that with colocated Git mode, my IDE highlights all the working copy changes as if they were uncommitted changes. Then I can easily see how much I’ve got left whether I’m in the terminal or the IDE. Good point about mixing in unrelated changes though, your way saves a step there I think.

This is very nice, I just tried it, thanks for the suggestion. I was messing around with rebasing subsequent PR updates onto the review commit but it got a bit messy with conflicts. The `jj restore` should solve it

I’ve been using it too, definitely recommend!

FYI if you click the share icon on a Kagi search, then others can see the results without needing to have a Kagi subscription themselves, e.g. https://kagi.com/search?q=copywork&r=ae&sh=d9jIEVVKaHzifbixh...

(https://help.kagi.com/kagi/features/share-results.html)

Maybe the refrigerator is the dock!

lol

On behalf of my friend: https://autono.ml

It is a wrapper over DuckDuckGo which redirects all searches without bangs to Google. It also changes the bang operator (!) to the open square bracket ([) because it is easier to type.

Very simple but effective time saver!

I haven't simulated this to check but it may be the case that IO pins become a limiting factor. The Cyclone IV has 153 IO pins so the design would have to use less than ~15 to be able to fit 10 copies on.

Well a CPU doesn't inherently use any I/O pins so that shouldn't be a problem.

You can easily add some logic to let CPUs share pins, too.

Good point sir