Son?

It's sometimes called "circular breathing." There are a few versions of an active breathing meditation called Quantum Light Breath (which has nothing to do with either quantum mechanics or light). It's definitely worth trying.

> which has nothing to do with either quantum mechanics or light

As is tradition with these kinds of things.

> discombobulates the fat particles

Hey, hey, hold on there Einstein. Enough with the technical jargon!

That seems essentially unreviewable. If you can share without violating an NDA, what kind of PR would involve that many files?

"Upgrade solution from .NET Framework 4.8 => .NET 8"

"Rename 'CustomerEmailAddress' to 'CustomerEmail'"

"Upgrade 3rd party API from v3 to v4"

I genuinely don't get this notion of a "max # of files in a PR". It all comes off to me as post hoc justification of really shitty technology decisions at GitHub.

It's not GitHub-specific advice, it's about reviewability of the PR vs. human working memory/maximum attention span.

I pretty frequently have conversations with other engineers where I point out that a piece of code makes an assumption that mostly holds true, but doesn't always hold true. Hence, a user visible bug.

The usual response is something like "if you're correct, wouldn't that mean there are hundreds of cases where this needs to be fixed to resolve this bug?". The answer obviously being yes. Incoming 100+ file PR to resolve this issue. I have no other ideas for how someone is supposed to resolve an issue in this scenario

How much working memory/attention span is required to look through 1000 identical lines "-CustomerEmailAddress +CustomerEmail"?

You're not just reviewing the individual lines, but also which context, and which files are impacted. And automating that part would still mean reviewing the automation and the 1000+ changes to move to it.

Sure 1000+ changes kills the soul, we're not good at that, but sometimes there's just no other decent choice.

Oh, certainly, didn't mean that you had to avoid using your IDE to autorename a variable yourself (to avoid the boolean issue) and diffed results to those of the PR

Or that you had to avoid Ctrl+F "CustomerEmail" and see whether you had 1000 matches that matches the number of changed files or only 999 due to some typo.

Or using the web interface to filter by file type to batch your reviews.

Or...

Just that in none of those cases there is anything close to our memory/attention capacity.

I envy your IDE being able to do a rename of that scale.

I work in a large C++ codebase and a rename like that will actually just crash my vscode instance straight-up.

(There are good automated tools that make it straightforward to script up a repository-wide mutation like this however. But they still generate PRs that require human review; in the case of the one I used, it'd break the PR up into tranches of 50-ish files per tranche and then hunt down individuals with authority to review the root directory of the tranche and assign it to them. Quite useful!)

Yeah VSCode is pretty terrible at refactorings that Jetbrains or Zed will do basically instantly.

We already automate that, it's called a compiler. The human review is just for kicks for this type of thing.

Of course some languages... PHP... aren't so lucky. $customer->cusomerEmail? Good luck dealing with that critical in production, fuckheads!

What if I told you there were tools for that

I'm aware of the tools, I write PHP daily.

The point is moreso that PHP won't stop you from doing that. It will run, and it will continue running, and then it will throw an error at some point. Maybe.

If the code is actually executed. If it's in a branch that's only executed like 1/1000 times... not good.

I've always thought those kinds of large-scale search-and-replace diffs should not generally be expected to be reviewed. If a review is 1000's of lines of identical changes (or newly-vendored code), literally nobody is actually reading it, even if they are somehow able to convince themselves that they are.

I would rather just see the steps you ran to generate the diff and review that instead.

> what kind of PR would involve that many files?

A very simple example: migrating from JavaEE to JakartaEE. Every single Java source file has to have the imports changed from "javax." to "jakarta.", which can easily be thousands of files. It's also easy to review (and any file which missed that change will fail when compiling on the CI).

If the project you're working on vendors dependencies it's pretty easy to end up with that many files being changed when adding or updating, even when trying to make as narrow updates as possible in one PR.

Convert space indents to tabs, as god intended.

as god indented, you mean?

I'm stealing that one, lmao

Ones where you have a lot of generated files you commit into Git, and you change the output of the generator tool.

Can’t speak for the person above but we keep a lot of configuration files in git and could easily write a thousand new configs in a single PR, or adding a new key to all the configs for example.

This is a well-written, interesting article. The only issue I have is with this:

> He said, if you tell someone you’re a journalist they’re going to believe you. Your job is to honor their trust.

Sadly, that is no longer true. Today's "journalists" far too often see their job as proselytizing rather than reporting.

Frankly, I'd like lawn darts back.

Or teach people how to point to a different DNS server in an area with laws more amenable to their preferences.

Until coutry implement the great firewall and it becomes a play of cat & mouse.

... or until the blocking starts at the root name servers. There are only a few of them.

The root zone file is publicly distributed by IANA [1] so you can download it and ignore the servers themselves. Then your lookup (from the resolver you're running yourself) starts at a particular country's top level.

As for censorship, because it's hierarchical, they'd have to remove an entire country code from the root servers.

[1] https://www.iana.org/domains/root/files

The usual response to this is that if you don't carry with a round in the chamber, you could spend the rest of your life racking the slide.

I regret that I have but one upvote to give to this comment.

Every time someone says "LLMs are good at boilerplate" my immediate response is "Why haven't you abstracted away the boilerplate?"

If what you say is true, we're very lucky no one like that with a massive following has ever gotten into politics in the United States. It would be an ongoing disaster!