the engine cannot brake to a complete stop, so break pads are always in use. At low RPMs, the engine is going to stall (manual) or switch to neutral (automatic).

It can brake to nearly a complete stop though with the brakes basically holding the car in place at the end. I got pretty good at it.

Brake wear scales ~quadratically with vehicle speed. Applying them at 5mph vs 20mph is 16x less energy to burn off.

For stacked diffs, check out https://gitpatch.com/

I actually prefer limited content width for prose content. Full width content on wide screens requires moving eyes all the way from one side to another for every line.

The real problem is that the browser won't let you control the width of a tab without resizing the browser window, which is a bit fiddly, exposes stuff behind the window, and makes you resize the window again and again when moving between tabs.

If you could easily shrink a tab, I would prefer websites to not limit text width. Since you can't, I sorta prefer them to do it, though it's much worse than the user controlling it in a nice per tab way

(1) reader mode (made for that purpose)

(2) user stylesheets (permanent solution, but you could have multiple and use an extension to enable disable different widths)

(3) responsive mode (in dev tools, most flexible, but most cumbersome to reach)

(4) Other extensions

There are easy ways to resize the viewport, so the premise is false.

you can "pop out" a single tab to a new window.

You could use the browser's dev tools to emulate a narrower viewport.

It should also be almost trivial to create a browser extension for this, if it doesn't even exist yet.

I use firefox's sidebar (vertical tabs) which makes resizing quite natural imo

I use the developer tools right panel for that.

Right, if you have wide columns then you have to move eyes BOTH from left to right AND when you reach the end of the line you have to move them back to left AND down to next line. Whereas if the line is narrow enough to read without moving eyes horizontally you only need to move your eyes down after each line.

Right, there is a reason why print magazines use columns even for long multi-page articles. With long lines, readers tend to get lost when navigating from the end of one line to the start of the next line, and the reading experience suffers. You can help this somehow by increasing spacing between the lines, but the general recommendation is to have 45-75 characters per line.

This bookmarklet to shrink the width has been in my toolbox for a long time: javascript:(function(){%20var%20myBody%20=%20document.getElementsByTagName('body')[0];%20var%20myBodyWidth%20=%20myBody.style.width;%20if%20(!myBodyWidth%20||%20myBodyWidth%20===%20'auto'%20||%20myBodyWidth%20===%20'inherit')%20{%20myBody.style.width%20=%20'1200px';%20myBody.style.marginLeft%20=%20'auto';%20myBody.style.marginRight%20=%20'auto';%20myBody.style.position%20=%20'relative';%20myBody.style.cssFloat%20=%20'none';%20}%20else%20{%20myBody.style.width%20=%20'auto';%20myBody.style.position%20=%20'static';%20}%20})();

Thanks that's an interesting trick.

This is beautified if somebody wants to see how it is done.

  function() {
    var myBody = document.getElementsByTagName('body')[0];
    var myBodyWidth = myBody.style.width;
    if (!myBodyWidth || myBodyWidth === 'auto' || myBodyWidth === 'inherit') {
        myBody.style.width = '1200px';
        myBody.style.marginLeft = 'auto';
        myBody.style.marginRight = 'auto';
        myBody.style.position = 'relative';
        myBody.style.cssFloat = 'none';
    } else {
        myBody.style.width = 'auto';
        myBody.style.position = 'static';
    }
  }

This summarizes the web ghetto pretty neatly.

I'm working on a new type of git forge[1], optimized for speed and work with patches.

It goes to extreme lengths to ensure great performance, i.e. rewritten most server-side parts of git from scratch, so there is no "exec"-ing git nor calls to libraries like libgit2. The frontend should also be very fast thanks for HTMX.

[1] https://gitpatch.com

Gitpatch attempts to solve this. Supports versioned patches and patch stacks (aka stacked PRs). Also handles force-pushes in stacks correctly even without Change-IDs using heuristics based on title, author date etc. It should also be unusually fast. Disclosure: I'm the author.

I'm not convinced that review comments as commits make thing easier, but I think storing them in git in some way is a good idea (i.e. git annotations or in commit messages after merge etc)

> in that every software engineer now depends heavily on copilots

With many engineers using copilots and since LLMs output the most frequent patterns, it's possible that more and more software is going to look the same, which would further reinforce the same patterns.

For example, emdash thing, requires additional prompts and instructions to override it. Doing anything unusual would require more effort.

Gitpatch author here.

Gitpatch attempts to build a Git hosting with native support for patches and commit-based review system, where each commit is its own patch. It's also smart to handle force pushes and can update or reorder patches as needed.

Gitpatch looks really great. And I greatly appreciate you listing out alternatives.

Do you have any plans to allow for self-hosting?

thanks for checking it out.

yeah, I plan to release it under AGPL at some point when it’s more complete. Currently it still needs more work. But no timeline yet.

I'll plug another option Gitpatch, however it's pretty early beta and not open-source yet, but most likely will be under AGPL at some point. It has built-in patch stacks (aka stacked PRs) and probably faster than any other Git host out there. disclosure: I'm the author.

I'm building a new Git hosting service, focused on performance and using HTMX. For example, compare page load time:

- https://gitpatch.com/gitpatch/git-demo

- https://github.com/git/git

How does this compare to codeberg?

Codeberg UI appears to be pretty similar to GitHub, so it's great as GitHub alternative. It's powered by Forgejo, fork of Gitea.

Gitpatch is a bit different. It implements a new storage backend and Git library from scratch. It also uses patch-based model for code review vs pull requests, where specially-named branches are used to submit patches and patch stacks.

I got so tired of waiting for GitHub pages taking ~600ms to load (uncached), so decided to build my own Git hosting service with Go and HTMX.

I know this is completely different scale, but compare: [1] https://github.com/git/git [2] https://gitpatch.com/gitpatch/git-demo

And there is no page cache. Sub 100ms is just completely different experience.

Very nice. Also a plea. Don't animate the >. Or, don't wait for the animation to finish before showing the contents.

ah, interesting. It starts fetching tree items on mousedown (vs onclick) to load them faster, so > starts moving a bit too early.