both options have their pros and cons. if you utilize some form of ratcheting[1], you can sneak it in without your team knowing.. but all of your PRs for the foreseeable future will have a ton of reformatting screwing with your git blame. if you do it all at once, someone will have to sort out conflicts, but you can utilize `blame.ignoreRevsFile`[2] so that your history remains useful

[1] https://github.com/diffplug/spotless/tree/main/plugin-gradle...

[2] https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

Even if you spread out reformatting over multiple commits in different PRs, you can still make use of blame.ignoreRevsFile as long as your pull request workflow doesn't enforce squash merges even when somebody took extra care to produce a nice commit history.

Yes, that is a good point. This is also why I personally would recommend to let a central person/team handle the reformatting rather than sneaking it into every PR (- see my sibling comment). That way you can be in charge of having a uniform style of commit messages to make the reformat commits easy to identify and create a well kept ignoreRevsFile. I think that provides the best of both worlds.

That’s a neat feature, thanks for sharing.

Unfortunately I find that code bases lacking auto formatting are often littered with non functional changes as developers temporarily instrument code, remove it, but leave whitespace changes behind.

In terms of tracking code changes, one really would have to rewrite the entire history with each commit reformatted.

not that mature — its name violates git’s trademark policy

https://git-scm.com/about/trademark

This is a meaningless fact unless Git actually sues them for infringement. Failure to quickly sue can be seen as tacit approval.

Do github, gitea, and gitlab not?

i can't speak to gitea, but github and gitlab are explicitly mentioned as having a license in their policy:

> Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.

From gitea:

GIT is a trademark of Software Freedom Conservancy and our use of “gitea” is under license.

just noting that pinning within your own actions is not enough, you also need to ensure any composite actions do not use mutable references (for actions, docker images, etc.)

while external merge queues offer a ton more features, i wouldn't describe any of them as 'perfect' based on the simple fact the UX is bolted on. github continues to display their native UI components for merging, and users are forced to interact via arcane commands in comments or external CLIs/webpages. not ideal!

> This report was produced by me — Claude Opus 4.6 — analyzing my own session logs [...] Please give me back my ability to think.

a bit ironic to utilize the tool that can't think to write up your report on said tool. that and this issue[1] demonstrate the extent folks become over reliant on LLMs. their review process let so many defects through that they now have to stop work and comb over everything they've shipped in the past 1.5 months! this is the future

[1] https://github.com/anthropics/claude-code/issues/42796#issue...

The other day I accidentally `git reset --hard` my work from April the 1st (wrong terminal window).

Not a lot of code was erased this way, but among it was a type definition I had Claude concoct, which I understood in terms of what it was supposed to guarantee, but could not recreate for a good hour.

Really easy to fall into this trap, especially now that results from search engines are so disappointing comparatively.

If your code was committed before the reset, check your git reflog for the lost code.

Yeah, git reset --hard is something I do like once a week! lol

With the reflog, as you mentioned, it's not hard to revert to any previous state.

Guess you’ve sorted it but it might be in the session memory in your root folder. I’ve recovered some things this way.

have you tried to recover it with git reflog?

https://oneuptime.com/blog/post/2026-01-24-git-reflog-recove...

you should limit your output (manual or assisted) to a level that is well under your understanding ceiling.

Kernighan’s Law states that debugging is twice as hard as writing. how do you ever intend on debugging something you can’t even write?

It's simple, they'll just let the LLM debug it!

This is why I believe the need for actually good engineers will never go away because LLMs will never be perfect.

Exactly. It's a force multiplier - sometimes the direction is wrong.

Same week I went into a deep rabbit hole with Claude and at no point did it try to steer me away from pursuing this direction, even though it was a dead end.

> Kernighan’s Law states that debugging is twice as hard as writing.

100%, but in a professional setting you often work with code _not_ written by you. What if that code is written by someone well above my ceiling?

They seem to have some notions of pipelines and metrics though. It could be argued that the hard part was setting up the observability pipeline in the first place - Claude just gets the data. Though if Claude is failing in such a spectacular way that the report is claiming, yes it is pretty funny that the report is also written by Claude, since this seems to be ejecting reasoning back to gpt4o territories

If you don't have swarms of agentic teams with layers of LLMs feeding and checking LLMs over and over again, you're going to be left behind.

pretty hard to find this on their blog, looks like incidents are tucked away at the bottom. an issue of this size deserve a higher spot.

(also looks like two versions of the 'postmortem' are published at https://blog.railway.com/engineering)

> there is a large force on HN that want to deny the value of tokens

there is an even larger force on HN that financially _needs_ the value of tokens to be inflated (so much so that bots have overwhelmed the site)

That’s not me. I am simply an engineer who gets a ton of value out of these tools.

That’s exactly what a bot would say ;-)

Really? Do you think there are more bots and employees of AI stakeholder companies than there are vanilla engineers on the site?

by far. at this point there are very few tech companies without exposure to AI

> Engineering salaries are significantly higher than nearly every other industry on average and on median

now compare the profit per employee at tech (software engineering) companies and those industries..

At the top end (say, top 100 tech companies) it’s pretty high indeed. Public companies, for sure, as otherwise their stock price would tank. It’s not uncommon in this industry to have margins above 70-80%.

But there are thousands if not tens of thousands where the profit per employee is minimal or negative.

I can’t find a source for all tech (the data wouldn’t exist for private firms anyway) but I think it’s telling to look at this list, scroll down to about the middle and look around at salaries you or your colleagues are pulling. Software revenues are certainly high but the industry is afloat because of these high margin businesses creating returns so that low margin businesses can exist. Without the massive infusion in upfront capital, very uncommon in other industries, it’s simply not sustainable.

Typically a market that’s buoyed by its top performers but has significant amounts of capital tied up in under performers is called “a bubble”.

https://www.trueup.io/revenue-per-employee

looking forward to the `addressing-githubs-recent-availability-issues-3` news post

structural search and replace in intellij is a superpower (within a single repo). for polyrepo setups, openrewrite is great. add in an orchestrator (simple enough to build one like sourcegraph's batch changes) and you can manage hundreds of repositories in a deterministic, testable way.