Git commands I run before reading any code • Hacker News Board

Re: Git commands I run before reading any code

#231

Post by goosejuice » Wed, Apr 08, 2026, 3:59 PM UTC

onion2k wrote: post #184

Supermancho wrote: post #159

Earlier quoted context omitted.

> I'm certain you can use change frequency as a proxy and never be wrong. I (largely) wrote a corporate application 8 years ago, with 2 others. There was one change 2 years ago from another dev. Lots of programs are functionally done in a relatively short amount of time. "Accelerating or Dying" sounds like private equity's lazy way to describe opportunity, not as a metric to describe software.

That sort of project exists in an ocean of abandoned and dead projects though. For every app that's finished and getting one update every few years there are thousands of projects that are utterly broken and undeployable, or abandoned on Github in an unfinished state, or sitting on someone's HDD never be to touched again. Assuming a low change frequency is a proxy for 'dead' is almost always correct, to the extent th…

With respect, this is a myopic view. Not all software is an "app" or a monolith. If you use a terminal, you are directly using many utilities that by this metric are considered dying or dead.

Re: Git commands I run before reading any code

#232

Post by xp84 » Wed, Apr 08, 2026, 4:00 PM UTC

wredcoll wrote: post #202

socalgal2 wrote: post #196

Earlier quoted context omitted.

a project isn’t dying because of no commits. Rather it’s stable I often feel I need to setup bots to make superfluous commits just to make it look like my useful and stable repos are “active” One example (not mine) a a qr-code generator library. Hasn’t been updated in 10 years. It’s perfect as is. It just provides the size and the bits. You convert those bits to any representation you want. It has no need to be updat…

It's rare, I think, for a project to have such a well defined and singular purpose that has not changed in 10 years nor have any bugs been discovered or its dependencies changed underneath it. It's not impossible, of course, but if I saw even a qr library that hadn't changed in 10 years I would worry that it wouldn't build on current systems (due to dependencies) and that nobody was actually using it (due to lag of b…

Well said. Even an awesome library with no bugs that has no external dependencies still depends on the stdlib. For a while, before we were using containers, we even had the issue on Mac dev machines especially, where a half dozen Rubygems would crash while building its C extensions if your Mac OS version wasn’t just what the author expected, due to changes in the compiler shipped by Apple. So a MacOS major update might on its own functionally break a gem, even if the gem itself was designed well and you were using the same Ruby version.

Re: Git commands I run before reading any code

#233

Post by jamwil » Wed, Apr 08, 2026, 4:02 PM UTC

furyofantares wrote: post #160

ramon156 wrote: post #5

> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.” The most changed file is the one people are afraid of touching?

The LLM that wrote the copy is an idiot.

This is such obvious LLM slop.

Re: Git commands I run before reading any code

#234

Post by plandis » Wed, Apr 08, 2026, 4:03 PM UTC

gib444 wrote: post #81

pzmarzly wrote: post #3

Jujutsu equivalents, if anyone is curious: What Changes the Most jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \ -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \ | sort | uniq -c | sort -nr | head -20 Who Built This jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \ -T 'self.author().name() ++ "\n"' \ | sort | uniq -c | sort -nr Where Do Bugs Cluster jj log --no-grap…

Hah someone really looked at jq (?) and thought: "yes, more of this everywhere". I feel jq is like marmite (edit: aka vegemite, i.e. "you either love it or you hate it")

It doesn't seem any more egregious than something like:

`git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit --`

Which is something I see a lot of people alias in Git for viewing logs.

Re: Git commands I run before reading any code

#235

Post by scottyah » Wed, Apr 08, 2026, 4:04 PM UTC

stronglikedan wrote: post #185

bsuvc wrote: post #90

I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now". It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful. AI generated commit messages helps this a lot, if de…

It's because the vast majority of commit messages are never read by anyone, and there's other ways to fund out what happened in the handful of cases where you would need to.

git blame's are amazing, and rely on good comments.

Re: Git commands I run before reading any code

#236

Post by md224 » Wed, Apr 08, 2026, 4:04 PM UTC

The last sentence of the article is "Here’s what the rest of the week looks like." and then it just stops. Am I missing something?

Re: Git commands I run before reading any code

#237

Post by BeetleB » Wed, Apr 08, 2026, 4:04 PM UTC

theshrike79 wrote: post #11

seba_dos1 wrote: post #8

> If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Squash-merge workflows are stupid (you lose information without gaining anything in return as it was easily filterable at retrieval anyway) and only useful as a workaround for people not knowing how to use git, but git stores the author and committer names separately, so it doesn't matter who merged, but rather wheth…

Can you explain to me (an avid squash-merger) what extra information do you gain by having commits that say "argh, let's see if this works", "crap, the CI is failing again, small fix to see if it works", "pushing before leaving for vacation" in the main git history? With a squash merge one PR is one commit, simple, clean and easy to roll back or cherry-pick to another branch.

Trivial and not too silly example:

Part of new feature you had working in an intermediate commit, but broke somewhere along the way and is not working in your last commit when you squashed.

If you catch it early enough, I suppose it's in your reflog, but otherwise you're screwed.

It sounds like a silly example, but I bet most developers have run into this at some point.

With mercurial/jujutsu, you get the best of both worlds: The "argh, let's see if this works" commits are what I call "microcommits", and the squashed versions are the real/public commits. With jujutsu, you get both. Your log shows only the "real" commits (equivalent of squashing all the commits between that and the prior "real" commit). But if you want to drill down into the microcommits, the information is always there.

Let's acknowledge the reality. Many people use git not just for version control, but for backup ("Let me commit this so I don't lose it"). Let's ensure the VC tool supports both and doesn't force you to pick one over the other.

Re: Git commands I run before reading any code

#238

Post by scottyah » Wed, Apr 08, 2026, 4:05 PM UTC

ryandrake wrote: post #193

ramijames wrote: post #124

Earlier quoted context omitted.

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.

Yes, and a culture problem, too. I guess I've been blessed that I've mostly only worked for "grown up" companies, but I've never encountered a workplace where people didn't write useful commit messages. At least one line description of the work done, but often multiple lines of valuable context. Only the junior devs had to be told to do it, but once they got into the habit, everyone understood why we do it and it was…

Some of my favorite are the perhaps well-meaning but totally misguided log of what files they changed.

Re: Git commands I run before reading any code

#239

Post by [deleted] » Wed, Apr 08, 2026, 4:07 PM UTC

jbjbjbjb wrote: post #79

Pay08 wrote: post #63

Earlier quoted context omitted.

Good thing that the article contains that warning, then.

Not really strong enough in a post about what to do in a codebase you’re not familiar with. In that situation you’re probably new to the team and organisation and likely to get off on the wrong foot with people if you assume their code “hurts”.

[deleted]

Re: Git commands I run before reading any code

#240

Post by bikelang » Wed, Apr 08, 2026, 4:07 PM UTC

bob1029 wrote: post #148

mikepurvis wrote: post #118

Earlier quoted context omitted.

In codebases where PRs are squashed on merge, the commit messages on the main branch end up being the PR body description text, and that's actually reviewed so tends to be much better I find.

And in every codebase I've been in charge of, each PR has one or more issue # linked which describe every possible antagonizing detail behind that work. I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.

I personally find this to be a substantially better pattern. That squashed commit also becomes the entire changeset - so from a code archeology perspective it becomes much easier to understand what and why. Especially if you have a team culture that values specific PRs that don’t include unrelated changes. I also find it thoroughly helpful to be able to see the PR discussions since the link is in the commit message.