Live data from Hacker News

Git commands I run before reading any code

piechowski.io

521–530 of 546 posts

Re: Git commands I run before reading any code

#521

I ran these commands on a number of codebases I work on and I have to say they paint a very different picture than the reality I know to be true. > git shortlog -sn --no-merges Is the most egregious. In one codebase there is a developer's name at the top of the list who outpaced the number 2 by almost 3x the number of commits. That developer no longer works at the company? Crisis? Nope, the opposite. The developer wa…

Same. Someone we brought on that worked for about a month and vibe coded to hell caused a lot of damage in terms of tech debt and that list shows. Looks like he managed 124 commits in a single week. The same repo, our top dev only has around 500 in its entirety. Also important to have a plan for code review and merges when a lead is out of town. I found out I needed to reevaluate how that's handed when I was gone for…

Not to diminish your lived experience, but this is sort of a management issue, no? There should be some expectations set and/or gates that need to be opened during PR about commit expectations. Some teams like a lot of commits to be a (messy) reflection of actual reality/history, others want the well-curated "story" with a bunch of squashes and rebases.

Re: Git commands I run before reading any code

#522

Earlier quoted context omitted.

The author does not look at counter values but rather at how the values changes. That reveals dynamics.

My comment still seems relevant? Do frequent commits to correct mistakes imply more "value" than infrequent, but well tested, commits, or what? I don't think it is a reliable signal.

It isn't. $COMPANY I've worked for use commit counts as a metric, and you can bet all the money in your pockets they've skyrocketed with no change to actual output after they did.

LLM's make it even easier; "Commit all the outstanding code in as many commits as you can, as long as the tests pass after each one". (Sometimes that second clause is ommitted, too.)

Re: Git commands I run before reading any code

#523
post #266

Earlier quoted context omitted.

I just use Claude Code as a terminal for git these days. It writes up better commit messages than I would write anyway. No more "git commit -m fix"

That could work if Claude Code made the code changes, but if you made them and only asked Claude to commit them, how does it know "why" you made those changes? Does it have access to your bug tracking system, for example?

> but if you made them and only asked Claude to commit them, how does it know "why" you made those changes?

It's an LLM. It can diff and figure out why I did what I did, in most cases

> Does it have access to your bug tracking system, for example?

You can give it access and tell it to look there

Re: Git commands I run before reading any code

#524

Earlier quoted context omitted.

Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4] If enough of the following apply strongly enough to your project: * Very small codebase * A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review * Not doing anything technically challengin…

> I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. This is classic dogmatics over pragmatics. The carpenter understands how to use every tool, they are just pragmatic about its use.

Again, in my experience, that isn't it. It's like NASA's rules. People who write garbage commit messages and have a chaotic and unconsidered version control workflow, generally lack the skill to do otherwise. As they lack version control skills, they haven't had the opportunity to internalise the benefits. Those with the skill to make disciplined use of version control tend to do so on every project, as the effort required is modest and is repaid even on minor projects.

We're talking about low-hanging fruit here. It's not like adopting the MISRA C programming style, which really does severely restrict the programmer.

Re: Git commands I run before reading any code

#525

Earlier quoted context omitted.

> I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. This is classic dogmatics over pragmatics. The carpenter understands how to use every tool, they are just pragmatic about its use.

Again, in my experience, that isn't it. It's like NASA's rules. People who write garbage commit messages and have a chaotic and unconsidered version control workflow, generally lack the skill to do otherwise. As they lack version control skills, they haven't had the opportunity to internalise the benefits. Those with the skill to make disciplined use of version control tend to do so on every project, as the effort re…

Becoming a pragmatic engineer takes time, you’ll get there one day. Best of luck.

Re: Git commands I run before reading any code

#526

Earlier quoted context omitted.

I think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.

I don't agree. These things actually matter. A developer who isn't told otherwise is just going to do whatever they feel like, so if there is nothing or no-one enforcing the standards, then the failure isn't on the individual developer, it is on the team lead. Someone needs to be setting the standards. In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a f…

This sounds a lot like the tactical tornado archetype.

From A Philosophy of Software Design by John Ousterhout:

> Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.

Re: Git commands I run before reading any code

#527

Earlier quoted context omitted.

Again, in my experience, that isn't it. It's like NASA's rules. People who write garbage commit messages and have a chaotic and unconsidered version control workflow, generally lack the skill to do otherwise. As they lack version control skills, they haven't had the opportunity to internalise the benefits. Those with the skill to make disciplined use of version control tend to do so on every project, as the effort re…

Becoming a pragmatic engineer takes time, you’ll get there one day. Best of luck.

Sloppy use of version control doesn't make you more effective. It just doesn't work that way.

Torvalds himself writes up proper commit messages even for his toy projects. [0][1] I really doubt it takes him much time or effort. You really think he's not pragmatic?

[0] https://github.com/torvalds/GuitarPedal/commits/main/?after=...

[1] https://github.com/torvalds/test-tlb/commits/master/

Re: Git commands I run before reading any code

#529
post #393

Earlier quoted context omitted.

I suspect OP never actually ran these commands and this article was brainstormed and written by an LLM.

There's some giveaways that it was too. "It's not x, its y."

I'm starting to feel that this line of reasoning has turned into pseudoscientific divination. And it's really unfair to writers who put effort into blog posts.

Re: Git commands I run before reading any code

#530

Some nice ideas but the regexes should include word boundaries. For example: git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | sort -nr | head -20 I have a project with a large package named "debugger". The presence of "bug" within "debugger" causes the original command to go crazy.

Word boundaries are one way to address that, but they require you to list all the inflections (and you missed “fixing”). Another way is to say (?<!de)bug.
Post reply on HN