Wrapping these in a TUI is on my list. Haven't built it yet.

Good catch. The word boundary syntax isn't portable across platforms. I reverted to the simpler version that works everywhere.

Sure, normalizing by size would be more precise. But this is a quick gut check to know which files to look at first, not a metric.

Fair point. I skip lockfiles, changelogs, and generated code. The first application file on the list is the one that matters. Should have been explicit about that in the post.

Only two of the five depend on commit messages. Churn, authorship, and velocity work regardless. Even teams with terrible hygiene write "fix" when something breaks.

As noted, authorship does not if commits are squashed, which seems to be common (I never do it).

> Even teams with terrible hygiene write "fix" when something breaks.

They might not include anything but the Jira ticket number, if the environment is truly lacking.

Big projects tend to self-correct. These commands hit differently on private codebases with 3-10 contributors, where high-churn usually means one person patching the same thing repeatedly.

Good catch, that's better

Very happy to hear!

Is this the same DPI device that snoops on DNS to shape bandwidth?

No. AFAIK it doesn't do any DPI. It's only for user messaging (content injection).

What? They just have to measure bandwidth from the other side of whatever is modifying the content.

Yes there is, it has to come from somewhere, and we know it's not coming from the actual site being visited...

>it has to come from somewhere

Very much doubt they count their traffic by adding up all the origin addresses contributions individually

Nope... The packets need to be sealed back together, at that point the data is denormalized and you can't measure how much it "actually" counted.

Huh? I happen to run my own intercepting proxy which rewrites HTML pages, and if I wanted to, I could easily track exactly how many bytes came in and how many bytes went out.