These are some helpful heuristics, thanks.This list is also one of many arguments for maintaining good Git discipline.

Tbf you wouldn&#x27;t use&#x2F;switch to jj for (because of) those kind of commands, and are quite the outlier in the grand list of reasons to use jj. However the option to use the revset language in that manner is a high-ranking reason to use jj in my opinion.The most frequent &quot;complex&quot; command I use is to find commits in my name that are unsigned, and then sign them (this is owing to my workflow with agents that commit on my behalf but I&#x27;m not going to give agents my private key!)<pre><code> jj log -r &#x27;mine() &amp; ~signed()&#x27;

 # or if yolo mode...

 jj sign -r &#x27;mine() &amp; ~signed()&#x27;
</code></pre>
I hadn&#x27;t even spared a moment to consider the git equivalent but I would humbly expect it to be quite obtuse.

No, jj is super simple in daily use, in contrast with git that is a constant chore (and any sane person use alias). This include stuff that in git is a total mess of complexity like dealing with rebases. So not judge the tool for this odd case.

It&#x27;s the dvorak of git... Maybe more efficient but incompatible with everyone else and a very loud vocal minority.You can find this pattern again and again. How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?

I don&#x27;t know about jujutsu, but I&#x27;ve actually found that Nix removes a lot of complexity. It&#x27;s essentially just npm for tooling.Managing a flake.nix can be a bit more complex than a package.json in practice, due to the flexibility of the format and some quirks around Nix&#x27;s default caching behavior, but working with it is a breath of fresh air compared relying on globally installed tools. Having said that, you might want to check out Devbox. I haven&#x27;t used it myself, but found it recently and thought it looked like a nice abstraction over raw Nix.

To be completely fair to JJ: you can still use git commands and any aliases with it.  I daily JJ in all of my repos but I created these aliases inside of git.  That&#x27;s one of the great aspects of JJ: it&#x27;s fully compatible with git.

Nix does not really work in that even basic things are absurdly complicated and can take days of messing with poor libraries and documentation.That&#x27;s not been my experience with jj which after the initial hurdle is a breeze.

To me, it makes jujutsu look like the Nix of VCSes.Not meaning to offend anyone: Nix is cool, but adds complexity. And as a disclaimer: I used jujutsu for a few months and went back to git. Mostly because git is wired in my fingers, and git is everywhere. Those examples of what jujutsu can do and not git sound nice, but in those few months I never remotely had a need for them, so it felt overkill for me.

If you copy those commands into a file and use that file to prompt the “sh” LLM.

Try <a href="https:&#x2F;&#x2F;cheat.sh&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cheat.sh&#x2F;</a>

I can&#x27;t remember all of this, does anyone know of any LLM model trained on CLI which can be run locally?

It&#x27;s really not that bad, although the jq comparison might be apt. You have such primitives you need to understand, and then everything just fits together nicely. I find this much easier to write and understand than git&#x27;s cryptic format strings.Disclaimer: I love jq too :)

It doesn&#x27;t seem any more egregious than something like:`git log --color --graph --pretty=format:&#x27;%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)&lt;%an&gt;%Creset&#x27; --abbrev-commit --`Which is something I see a lot of people alias in Git for viewing logs.

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

Same, but now with AI I don&#x27;t have to remember that anymore

I don&#x27;t, I will google things and fiddle, then put it in a git alias (with a comment on what it does and &#x2F; or where I got it from) and push it to my private dotfiles repo, taking it with me between computers and projects.

I am convinced that the vast majority of professionals simply don&#x27;t bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage.At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there&#x27;s effectively no other choice.That said, the OP&#x27;s commands are useful, I am copying them (because obviously I won&#x27;t ever memorize them).

You research it once, use it and then remember that it has &quot;ancestor&quot; in the command somewhere and then use ctrl + R to dig up something from your shell history.

If I look something up twice, I record it in Obsidian. If I need it more than a couple of times, I&#x27;ll probably make an alias, a script or a mask [1] file. Autocomplete and autosuggest are essential to my workflow. And good history search.[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jacobdeichert&#x2F;mask" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jacobdeichert&#x2F;mask</a>

If you don&#x27;t have to codedive new projects all the time, there&#x27;s zero reason to memorize these. If your job is to look at new codebases all the time, you probably learn to remember these commands pretty quickly.

Yeah especially with git. All I know is pull, add, commit, push. Everything else I have to look up.

&gt; I don’t understand how people can remember all these custom scripting languages.We can&#x27;t.Why do you think the `man` command exists?

Nobody does. One person figures it out, then writes a blog post, and we all Google for it. Even git’s man pages are long and sometimes cryptic.

You add them into your GIT config file as shortcuts?If you have multiple machines (&#x2F;must have), just apply your user config to current machine?

jj&#x27;s template and revset languages are very simple syntactically, so once you&#x27;re comfortable with the few things you do use often it&#x27;s just a question of learning about the other existing functions (even if only enough to know to look them up), which slot right in and compose well with everything else you know (unlike flags which typically have each their own system).Or, perhaps better yet, defining your own functions&#x2F;helpers as you go for things you might care about, which, by virtue of having been named you, are much easier to remember (and still compose nicely).

Some things are idioms that one repeats so often they just stick, e.g. I use &quot;grep.... | cut -c x-y | sort | uniq -c | sort -nr&quot; to quickly grep frequency of some events from a log file.Don&#x27;t feel bad - no one remembers them all, we just remember a few idioms we use...

So, how does one iterate over an array in jq? Asking for a friend.

You and me both. Git is just so prevalent and fundamental to so much these days that I forced myself to use only a cheat sheet lying on my desk until I could comfortably use a reasonably productive subset by memory. Little did I know that that would make my colleagues think I&#x27;m some sort of git sage.But jq I use maybe once a week, and it just won&#x27;t stick. Same for any git features beyond basic wrangling of the history tree (but, on the flip side, that basic wrangling has eliminated 99% of the times I have to look things up).

People naturally remember what they use frequently. For things they use infrequently, they search on-line and&#x2F;or read the friendly manual.And yes, I&#x27;m also ecstatic when I manage to iterate over anything in `jq` without giving up and reaching for online reference. For `git`, functionality I use divides neatly into &quot;things I do at least every week or two&quot; and &quot;things that make me reach for the git book every single time&quot;.I mean, that was true until ~year or so. Now, I just have an LLM on speed dial. `howto do xyz in $tool`, `wtf is git --blah`, `oneliner for frobbing the widget`, etc.

lazygit helped me to get more into different git commands - I still don&#x27;t know them by heart. but at least I use more git has to offer.and when a new branch is one key stroe away from being created, I am more inclined to use it.

`jq` and `ffmpeg` were two of my very early uses of LLM&#x27;s for daily ease.

I don’t understand how people can remember all these custom scripting languages. I can’t even remember most git flags, I’m ecstatic when I remember how to iterate over arrays in “jq”, I can’t fathom how people remember these types of syntaxes.

It&#x27;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&#x27;s not impossible, of course, but if I saw even a qr library that hadn&#x27;t changed in 10 years I would worry that it wouldn&#x27;t build on current systems (due to dependencies) and that nobody was actually using it (due to lag of bug reports).

&gt; a project isn’t dying because of no commits. Rather it’s stableAgreed. Assuming there are no open issues and PRs. When I find a project, if the date of the last commit is old, I next look at the issues and PRs. If there are simple-to-deal-with issues (e.g. a short question or spam) and easy-to-merge PRs (e.g. fixing a typo in the README) which have been left lingering for years, it’s probably abandoned. Looking at the maintainer’s GitHub activity graph should provide more clues.&gt; 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”I have never done it, but a few times thought about making a “maintenance” release to bump the version number and release date, especially since I often use a variant of calendar versioning.

This might be true for libraries or utilities that have a well-defined scope and no dependencies, but that&#x27;s not what the article is focused on. When considering a company&#x27;s main product, it&#x27;s usually never done and patterns of activity—and especially changes in those patterns—can give you insight into potential issues.

In a real company?  A private codebase at a minimum should still be getting regular security patching and dependency updates.  Always eventually one of those updates requires some level of refactor.  If I see a project with no commits, I run away.

a project isn’t dying because of no commits. Rather it’s stableI 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 updated

But the git commands in the article is also programming of the same kind, just using more terse, more obscure language. All the shell pipelines are sort, uniq, and grep.A language that properly maps to the data model, and has readable identifiers is a boon. Git is a database, a database needs a proper query language.

I don&#x27;t want to program git, I want to get stuff done so I would reject using that tool and do what the article author did running tried and true pipeable Linux&#x2F;UNIX commands. It&#x27;s also the same reason why I dislike Gradle and use Maven, I don&#x27;t want to program my build I want to define and run my build.

This is the only sane reply on this entire comment tree.To me, the verbosity of both Git and JJ commands to do these things are an indication that neither of these tools are meant to do them.

crying over? Let&#x27;s not be confrontational. I could say you&#x27;re &quot;crying&quot; with this comment, but is that a good thing to say?

Saw all the replies crying over how verbose these are, clicked through to TFA expecting to see simpler commands. Nope, they&#x27;re basically the same thing, just slightly shorter. I would never memorize either the jj or git versions if I planned to use them regularly; I&#x27;d make aliases.

Cool! Thanks :)
Jujutsu is such a nice tool. I don&#x27;t understand why everything has to be so divisive nowadays. Enjoy the tools you like.

Jujutsu equivalents, if anyone is curious:What Changes the Most<pre><code> jj log --no-graph -r &#x27;ancestors(trunk()) &amp; committer_date(after:&quot;1 year ago&quot;)&#x27; \
 -T &#x27;self.diff().files().map(|f| f.path() ++ &quot;\n&quot;).join(&quot;&quot;)&#x27; \
 | sort | uniq -c | sort -nr | head -20
</code></pre>
Who Built This<pre><code> jj log --no-graph -r &#x27;ancestors(trunk()) &amp; ~merges()&#x27; \
 -T &#x27;self.author().name() ++ &quot;\n&quot;&#x27; \
 | sort | uniq -c | sort -nr
</code></pre>
Where Do Bugs Cluster<pre><code> jj log --no-graph -r &#x27;ancestors(trunk()) &amp; description(regex:&quot;(?i)fix|bug|broken&quot;)&#x27; \
 -T &#x27;self.diff().files().map(|f| f.path() ++ &quot;\n&quot;).join(&quot;&quot;)&#x27; \
 | sort | uniq -c | sort -nr | head -20
</code></pre>
Is This Project Accelerating or Dying<pre><code> jj log --no-graph -r &#x27;ancestors(trunk())&#x27; \
 -T &#x27;self.committer().timestamp().format(&quot;%Y-%m&quot;) ++ &quot;\n&quot;&#x27; \
 | sort | uniq -c
</code></pre>
How Often Is the Team Firefighting<pre><code> jj log --no-graph \
 -r &#x27;ancestors(trunk()) &amp; committer_date(after:&quot;1 year ago&quot;) &amp; description(regex:&quot;(?i)revert|hotfix|emergency|rollback&quot;)&#x27;
</code></pre>
Much more verbose, closer to programming than shell scripting. But less flags to remember.

Yes. Because the fear is butressed with necessity. You have to edit the file, and so does everyone else and that is a recipe for a lot of mess. I can think back over years of files like this. Usually kilolines of impossible to reason about doeverything.

Yeah same thing happens with lockfiles and CI configs. You end up filtering out half the list before it tells you anything useful.

I just tried it too and it basically just flagged a handful of 1500+ line files which probably ought to be broken up eventually but arent causing any serious problems.

I&#x27;d only look at human&#x2F;AI edited files (i.e. that require some kind of reasoning) not generated ones (where the reasoning is in the generator).Generation is precompilation.Entry point is interesting. Lots of scope to become a scary file.

I&#x27;ve just tried this, and the most touched files are also the most irrelevant or boring files (auto generated, entry-point of the service etc.) in my tests.

Could be also that a frequently edited file had most opportunity to be broken. And it was edited by the most random crowd.

Just like that place that&#x27;s so crowded nobody goes there anymore.

Definitely not in my experience. The most changed are the change logs, files with version numbers and readmes. I don&#x27;t think anyone is afraid of keeping those up to date.

Good thing that the article contains that warning, then.

Better for people to know they&#x27;re just blindly copying tools and parroting their output as if it&#x27;s automatically meaningfully. Any warning against that should be built into the individual, for their own sake

These commands are just about what files to start looking at to understand new codebase.

I found it interesting, that Git itself has built in similarity notion... when it packs objects, it groups files by path+size, runs delta cmpression to find which are close.Very different from just counting commits - <a href="https:&#x2F;&#x2F;vectree.io&#x2F;c&#x2F;delta-compression-heuristics-and-packfile-binary-format-in-git" rel="nofollow">https:&#x2F;&#x2F;vectree.io&#x2F;c&#x2F;delta-compression-heuristics-and-packfi...</a>

This command needs a warning. Using this command and drawing too many conclusions from it, especially if you’re new, will make you look stupid in front of your team mates.I ran this on the repo I have open and after I filtered out the non code files it really can only tell me which features we worked on in the last year. It says more about how we decided to split up the features into increments than anything to do with bugs and “churn”.

Why does github owners need frequent change? Do members in you team change so often?

In my case, it&#x27;s .github&#x2F;CODEOWNERS.Nobody is afraid of changing it.

Yeah, the truth is going to be a lot more subtle than this.

Plotting Churn against Complexity is far more useful than merely churn.It shows places that are problematic much better. High churn, low complexity: fine. Its recognized and optimizef that this is worked on a lot (e.g. some mapping file, a dsl, business rules etc). Low churn high complexity: fine too. Its a mess, but no-one has to be there.
But both? Thats probably where most bugs originate, where PRs block, where test coverage is poor and where everyone knows time is needed to refactor.In fact, quite often I found that a teams&#x27; call &quot;to rewrite the app from scratch&quot; was really about those few high-churn-high-complexity modules, files or classes.Complexity is a deep topic, but even simple checks like how nested smt is, or how many statements can do.

pom.xml and package.json came up on couple of separate projects I ran the commands on. Which makes sense because the versions get bumped rather frequently. I guess context matters, as usual.

Maybe it&#x27;s a start to find conflict-prone regions ?otherwise you&#x27;re right, it could be a long linear list of appends where people are happy to contribute.

That&#x27;s the one that always broke something down the line leading to a stream of reverts and retries?

&gt; 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?

These commits reaching the reviewer are a sign of either not knowing how to use git or not respecting their time. You clean things up and split into logical chunks when you get ready to push into a shared place.

If someone uses git commits like the save function of their editor and doesn&#x27;t write messages intended for reading by anyone else, it makes sense to want to hide themFor other cases, you lose the information about why things are this way. It&#x27;s too verbose to &#x2F;&#x2F;comment on every like with how it came to be this way but on (non-rare in total, but rare per line) occasion it&#x27;s useful to see what the change was that made the line be like this, or even just who to potentially ask for help (when &gt;1 person worked on a feature branch, which I&#x27;d say is common)

You gain the extra information by having reasonable commit messages rather than the ones you mentioned. To fix CI you force push.Can you explain to me what an avid squash-merger puts into the commit message of the squashed commit composed of commits &quot;argh, let&#x27;s see if this works&quot;, &quot;crap, the CI is failing again, small fix to see if it works&quot;, and &quot;pushing before leaving for vacation&quot; ?

Why are those commits ending in the PR? Just unprofessional to work like that.

&gt; &quot;argh, let&#x27;s see if this works&quot;, &quot;crap, the CI is failing again, small fix to see if it works&quot;, &quot;pushing before leaving for vacation&quot;These are all bad commits IMHO. Aside from the CI one, I understand that message. I have commits like that on personal projects but for professional projects I&#x27;d be frustrated if people were committing messages like that.Personally I&#x27;m a &quot;one commit&quot; type of guy, I don&#x27;t like committing things in a broken state even on a side branch unless I have to (to share the code or test a CI). Occasionally I will make multiple commits at the very end to make review easier or once I have everything working but I want to try something different but I have a bunch of options of saving code that don&#x27;t involving committing:- Stash- Shevle (IDEA)- Backblaze- Time Machine- Local History (IDEA)The idea of committing WIP before leaving for a vacation just feels so wrong to me.I once worked for someone who wanted developers to commit code before the end of every day as a safety measure. His reasoning was in case the developer&#x27;s computer died or similar. I found that silly at the time and still do now. That&#x27;s what backups are for, I dislike when people use git as a backup like that in a professional setting.

git bisect gets more useful because it will pin a smaller set of changes

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&#x27;s in your reflog, but otherwise you&#x27;re screwed.It sounds like a silly example, but I bet most developers have run into this at some point.With mercurial&#x2F;jujutsu, you get the best of both worlds: The &quot;argh, let&#x27;s see if this works&quot; commits are what I call &quot;microcommits&quot;, and the squashed versions are the real&#x2F;public commits. With jujutsu, you get both. Your log shows only the &quot;real&quot; commits (equivalent of squashing all the commits between that and the prior &quot;real&quot; commit). But if you want to drill down into the microcommits, the information is always there.Let&#x27;s acknowledge the reality. Many people use git not just for version control, but for backup (&quot;Let me commit this so I don&#x27;t lose it&quot;). Let&#x27;s ensure the VC tool supports both and doesn&#x27;t force you to pick one over the other.

Can you explain to me (an avid squash-merger) what extra information do you gain by having commits that say &quot;argh, let&#x27;s see if this works&quot;, &quot;crap, the CI is failing again, small fix to see if it works&quot;, &quot;pushing before leaving for vacation&quot; 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.

Having the commit graph easy to filter means exactly that you don&#x27;t have to sift through hundreds of commits for no reason. What else did you think it would mean?

Having the tree easy to filter doesn&#x27;t matter if it returns hundreds of commits you have to sift through for no reason.

I don&#x27;t think there&#x27;s much nuance in the &quot;I don&#x27;t know --first-parent exists&quot; workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can&#x27;t use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that&#x27;s pretty much the only time you actually have a good reason to do that.

I think the point is that if you have to squash, the PR-maker was already gitting wrong. They should have &quot;squashed&quot; on their end to one or more smaller, logically coherent commits, and then submitted that result.

The author is talking about the case where you have coherent commits, probably from multiple PRs&#x2F;merges, that get merged into a main branch as a single commit.Yeah, I can imagine it being annoying that sqashing in that case wipes the author attribution, when not everybody is doing PRs against the main branch.However, calling all squash-merge workflows &quot;stupid&quot; without any nuance.. well that&#x27;s &quot;stupid&quot; :)

Yes, I think people who are anti squash merge are those who don&#x27;t work in Github and use a patch based system or something different. If you&#x27;re sending a patch for linux, yes it makes sense that you want to send one complete, well described patch. But Github&#x27;s tooling is based around the squash merge. It works well and I don&#x27;t know anyone in real life who has issues with it.And to counter some specific points:* In a github PR, you write the main commit msg and description once per PR, then you tack on as many commits as you want, and everyone knows they&#x27;re all just pieces of work towards the main goal of the eventually squashed commit* Forcing a clean up every time you make a new commit is not only annoying extra work, but it also overwrites history that might be important for the review of that PR (but not important for what ends up in main branch).* When follow up is requested, you can just tack on new commits, and reviewers can easily see what new code was added since their last review. If you had to force overwrite your whole commit chain for the PR, this becomes very annoying and not useful to reviewers.* In the end, squash merge means you clean up things once, instead of potentially many times

If your goal here is to have linear history, then just use a merge commit when merging the PR to main and always use `git log --first-parent`. That will only show commits directly on main, and gives you a clean, linear history.If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value.You can also cherry pick or rollback the single merge commit, as it holds everything under it as a single unit.This avoids changing history, and importantly, allows stacked PRs to exist cleanly.

&gt; But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.They&#x27;re not noise, they tell future maintainers why something is the way it is. If it&#x27;s done in an unusual way they can see in the blame that a couple of lines were changed separately from the rest and immediately get an explanation by checking that commit.

Squash merge is the only reasonable way to use GitHub:If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits.But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.So sure, there’s workflows with Git that doesn’t need squashing. But they’re incompatible with GitHub, which is at least where I keep my code today.Is it perfect? No. But neither is git, and I live in the world I am given.

Squash-merge is entirely fine for small PRs. Cleaning up the commits in advance (probably to just squash them to one or two anyway) is extra work, and anything that discourages people from pushing often (to get the code off their local machine) needs to be well-justified. Just review the (smallish!) total outcome of all the commits and squash after review. A few well-placed messages on the commit, attached to relevant lines, are more helpful and less work than cleaning up the commit history of a smallish PR.For really large PRs, I’m more inclined to agree with you, but those should probably have their own small-PR-and-squash-merge flow that naturally cleans up their git history, anyway.I categorically disagree that squash-merge is “stupid” but agree there are many ways to skin this cat.

The commit graph is a full-blown DAG that you can operate on and form in any way you like that helps you achieve your goals. When merging something in you get back pointers to (at least) two parents that let you see what came from which branch, and a merge commit has its own commit message that lets you describe overarching goals. Even when doing rebase-before-merge flow you can still group things by merge commits, which are often used to have PRs referenced in the repository while keeping the history effectively linear and easy to browse. This way you keep the one central unit of information management in Git representing what it&#x27;s supposed to - the atomic unit of change that you can build upon and traverse in various ways depending on context, rather than force larger things to squeeze into it for no good reason.(and if you hadn&#x27;t squashed on merge, short-lived branches wouldn&#x27;t even &quot;disappear&quot; in the first place as you would still see them decorated in &quot;git log&quot; on commits that were merged in)

How does not squash merging deal with the fact that branches disappear when merging? What I mean is that the information &quot;this commit happened in the context of this PR or this overarching goal&quot; goes missing. When you squash, you use the one central unit of information management in Git: the commit.

Calling squash stupid sounds like a case of Dunning-Kruger.If you&#x27;ve worked on a large team without squashing and without increasing frustration I&#x27;d be greatly interested to hear about it.

&gt; 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&#x27;t matter who merged, but rather whether the squashed patchset consisted of commits with multiple authors (and even then you could store it with Co-authored-by trailers, but that&#x27;s harder to use in such oneliners).

&gt; Why would you touch the README file hundreds of times a year?You&#x27;re right, perhaps I should have said CHANGELOG etc.Although some projects e.g. bump version numbers in README or add extra one-liner examples ....

Some readme files include changelogs. But aside from that I think this can still net some useful information. I like to look at the most recently changed files in a repo as well.

Why would you touch the README file hundreds of times a year?You&#x27;re right about package.json, pnpm-lock etc though, but those are easy to filter out if the project in question uses them.

It’s easy enough to filter those out with grep. It still is relatively meaningless. If the team incrementally adds things then it’s just going to show what additions were made. It isn’t churn at all.

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.

&gt; The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about.What a weird check and assumption.I mean, surely most of the &quot;20 most-changed files&quot; will be README and docs, plus language-specific lock-files etc. ?So if you&#x27;re not accounting for those in your git&#x2F;jj syntax you&#x27;re going to end up with an awful lot of false-positive noise.

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

Similarly, we have a technical concept called &quot;rollback&quot; that is unrelated to a reverted commit.

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 (?&lt;!de)bug.

Great tips, added to notes.txt for future use ..Another one I do, is:<pre><code> $alias gss=&#x27;git for-each-ref --sort=-committerdate&#x27;

 $gss

 ce652ca83817e83f6041f7e5cd177f2d023a5489 commit refs&#x2F;heads&#x2F;project-feature-development
 ce652ca83817e83f6041f7e5cd177f2d023a5489 commit refs&#x2F;remotes&#x2F;origin&#x2F;project-feature-development
 1ef272ea1d3552b59c3d22478afa9819d90dfb39 commit refs&#x2F;remotes&#x2F;origin&#x2F;feature&#x2F;feature-removal-from-good-state
 c30b4c67298a5fa944d0b387119c1e5ddaf551f1 commit refs&#x2F;remotes&#x2F;origin&#x2F;feature&#x2F;feature-removal
 eda340eb2c9e75eeb650b5a8850b1879b6b1f704 commit refs&#x2F;remotes&#x2F;origin&#x2F;HEAD
 eda340eb2c9e75eeb650b5a8850b1879b6b1f704 commit refs&#x2F;remotes&#x2F;origin&#x2F;main
 3f874b24fd49c1011e6866c8ec0f259991a24c94 commit refs&#x2F;heads&#x2F;project-bugfix-emergency
 ...

</code></pre>
This way I can see right away which branches are &#x27;ahead&#x27; of the pack, what &#x27;the pack&#x27; looks like, and what is up and coming for future reference ... in fact I use the &#x27;gss&#x27; alias to find out whats going on, regularly, i.e. &quot;git fetch --all &amp;&amp; gss&quot; - doing this regularly, and even historically logging it to a file on login, helps see activity in the repo without too much digging. I just watch the hashes.

It&#x27;s a very old config that I copied from someone many years ago, agree that it&#x27;s a bit hard to parse visually.

Not the poster, but one theory: so you only need to copy one file. Portability.

Curious - why write it as a function in presumably .gitconfig and not just a git-summary script in your path? Just seems like a lot of extra escapes and quotes and stuff

+1 Same.Edit.
<a href="https:&#x2F;&#x2F;github.com&#x2F;mattrighetti&#x2F;dotfiles&#x2F;blob&#x2F;master&#x2F;.gitconfig" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mattrighetti&#x2F;dotfiles&#x2F;blob&#x2F;master&#x2F;.gitcon...</a>

Looks nice. Unfortunately I don&#x27;t have log-of-count-and-email, log-of-count-and-day or churn

I was going to say, the OP&#x27;s assertion that &quot;they&quot; are typing all these commands out by hand each time without an alias is just one of many tells that this post is AI slop. Nobody that proficient with shell commands should be typing any of those by hand more than once or twice without aliasing for reuse.

I have a summary alias that kind of does similar things<pre><code> # summary: print a helpful summary of some typical metrics
 summary = &quot;!f() { \
 printf \&quot;Summary of this branch...\n\&quot;; \
 printf \&quot;%s\n\&quot; $(git rev-parse --abbrev-ref HEAD); \
 printf \&quot;%s first commit timestamp\n\&quot; $(git log --date-order --format=%cI | tail -1); \
 printf \&quot;%s latest commit timestamp\n\&quot; $(git log -1 --date-order --format=%cI); \
 printf \&quot;%d commit count\n\&quot; $(git rev-list --count HEAD); \
 printf \&quot;%d date count\n\&quot; $(git log --format=oneline --format=\&quot;%ad\&quot; --date=format:\&quot;%Y-%m-%d\&quot; | awk &#x27;{a[$0]=1}END{for(i in a){n++;} print n}&#x27;); \
 printf \&quot;%d tag count\n\&quot; $(git tag | wc -l); \
 printf \&quot;%d author count\n\&quot; $(git log --format=oneline --format=\&quot;%aE\&quot; | awk &#x27;{a[$0]=1}END{for(i in a){n++;} print n}&#x27;); \
 printf \&quot;%d committer count\n\&quot; $(git log --format=oneline --format=\&quot;%cE\&quot; | awk &#x27;{a[$0]=1}END{for(i in a){n++;} print n}&#x27;); \
 printf \&quot;%d local branch count\n\&quot; $(git branch | grep -v \&quot; -&gt; \&quot; | wc -l); \
 printf \&quot;%d remote branch count\n\&quot; $(git branch -r | grep -v \&quot; -&gt; \&quot; | wc -l); \
 printf \&quot;\nSummary of this directory...\n\&quot;; \
 printf \&quot;%s\n\&quot; $(pwd); \
 printf \&quot;%d file count via git ls-files\n\&quot; $(git ls-files | wc -l); \
 printf \&quot;%d file count via find command\n\&quot; $(find . | wc -l); \
 printf \&quot;%d disk usage\n\&quot; $(du -s | awk &#x27;{print $1}&#x27;); \
 printf \&quot;\nMost-active authors, with commit count and %%...\n\&quot;; git log-of-count-and-email | head -7; \
 printf \&quot;\nMost-active dates, with commit count and %%...\n\&quot;; git log-of-count-and-day | head -7; \
 printf \&quot;\nMost-active files, with churn count\n\&quot;; git churn | head -7; \
 }; f&quot;
</code></pre>
EDIT: props to <a href="https:&#x2F;&#x2F;github.com&#x2F;GitAlias&#x2F;gitalias" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GitAlias&#x2F;gitalias</a>

I also feel this reads like an AI slop, but at least I learned 5 commands. Not too bad.

Rather than using an LLM to write fluffy paragraphs explaining what each command does and what it tells them, the author should have shown their output (truncated if necessary)

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.

Just looking at how often a file changes without knowing how big the file is seems a bit silly. Surely it should be changes&#x2F;line or something?

Yes for a meaningful context you should need both the source repo and the work tracking system. But today most systems have apis (jira, ADO, gh, ...) so this should be fairly doable, especially using a bot like copilot cli. But it&#x27;s not doable as a little shell script.

For the stuff I&#x27;ve worked on, if you want to know about bugfixes and emergency releases, you&#x27;d go to Jira where those values are formalized as fields. Someone else in the comments here had a suggestion which just looks for the word &quot;fix&quot; which would definitely capture some bugfix releases, but is more likely to catch fixes that were done during development of a feature.

We use branch names like `hotfix&#x2F;some-hotfix-name`, don&#x27;t think I&#x27;ve seen many commits mention hotfix directly.

Trusting the messages to contain specific keywords seems optimistic. I don&#x27;t think I used &quot;emergency&quot; or &quot;hotfix&quot; ever. &quot;Revert&quot; is some times automatically created by some tools (E.g. un-merging a PR).

Ages ago, google released an algorithm to identify hotspots in code by using commit messages. <a href="https:&#x2F;&#x2F;github.com&#x2F;niedbalski&#x2F;python-bugspots" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;niedbalski&#x2F;python-bugspots</a>

Ages ago google wrote an algorithm to detect hotspots by using commit messages, <a href="https:&#x2F;&#x2F;github.com&#x2F;niedbalski&#x2F;python-bugspots" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;niedbalski&#x2F;python-bugspots</a>

&gt; One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions.In my experience, when the team doesn&#x27;t squash, this will reflect the messiest members of the team.The top committer on the repository I maintain has 8x more commits than the second one. They were fired before I joined and nobody even remembers what they did. Git itself says: not much, just changing the same few files over and over.Of course if nobody is making a mess in their own commits, this is not an issue. But if they are, squash can be quite more truthful.

For more insights on Git, check out <a href="https:&#x2F;&#x2F;github.com&#x2F;nolasoft&#x2F;okgit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nolasoft&#x2F;okgit</a>

Instead of focusing on the top 20 files, you can map the entire codebase with data taken from git log using ArcheoloGit [1].[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;marmelab&#x2F;ArcheoloGit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;marmelab&#x2F;ArcheoloGit</a>

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.

This is better than the post itself. Showing real output from a real repo.

I was curious what information I could glean from these for some popular repos. Caveat: I&#x27;m primarily an low-level embedded developer so I don&#x27;t interface with large open source projects at the source level very often (other than occasionally the linux kernel). I chose some projects at random that I use.*Mainline linux*Most changed files: pretty much what I expected for 1 and 2... the &quot;cutting edge&quot; of Linux development over other OSes -- bpf and containers. The bpf verifier and AMD GPU driver might get a boost in this list due to sheer LoCs in those files (26K and 14K respectively). An intel equivalent of amdgpu_dm is #21 in the list (drivers&#x2F;gpu&#x2F;drm&#x2F;i915&#x2F;display&#x2F;intel_display.c) and nvidia is nowhere to be seen (presumably due to out-of-tree modules&#x2F;blobs?).<pre><code> 186 kernel&#x2F;bpf&#x2F;verifier.c
 174 fs&#x2F;namespace.c
 162 drivers&#x2F;gpu&#x2F;drm&#x2F;amd&#x2F;display&#x2F;amdgpu_dm&#x2F;amdgpu_dm.c
 161 kernel&#x2F;sched&#x2F;ext.c
 159 fs&#x2F;f2fs&#x2F;f2fs.h
</code></pre>
Bus factor: obviously none. The top 4<pre><code> 10399 Christoph Hellwig -&gt; I only know his name because of drama last year regarding rust bindings to DMA subsystem
 8481 Mauro Carvalho Chehab -&gt; I also know his name from the classic &quot;Mauro, shut the fuck up!&quot; Linus rant
 8413 Takashi Iwai -&gt; Listed as maintainer for sound subsystem, I think he manages ALSA
 8072 Al Viro -&gt; His name is all over bunch of filesystem code
</code></pre>
Buggy files: Intel comes out on top of GPU drivers this time (twice). Along with KVM for x86(64), the main allocator, and BTRFS.<pre><code> 1477 drivers&#x2F;gpu&#x2F;drm&#x2F;i915&#x2F;intel_display.c
 1406 MAINTAINERS
 1390 sound&#x2F;pci&#x2F;hda&#x2F;patch_realtek.c
 1102 drivers&#x2F;gpu&#x2F;drm&#x2F;i915&#x2F;i915_drv.h
 943 arch&#x2F;x86&#x2F;kvm&#x2F;x86.c
 928 mm&#x2F;page_alloc.c
 871 drivers&#x2F;gpu&#x2F;drm&#x2F;amd&#x2F;display&#x2F;amdgpu_dm&#x2F;amdgpu_dm.c
 862 drivers&#x2F;gpu&#x2F;drm&#x2F;i915&#x2F;i915_reg.h
 840 fs&#x2F;btrfs&#x2F;inode.c
</code></pre>
*GCC*Most changed files: IR autovectorization code, riscv heuristics tables, and C++ template handling (pt.c is &quot;paramaterized types&quot;).<pre><code> 152 gcc&#x2F;tree-vect-stmts.cc
 145 gcc&#x2F;config&#x2F;riscv&#x2F;riscv.cc
 131 gcc&#x2F;tree-vect-loop.cc
 116 gcc&#x2F;cp&#x2F;pt.cc
</code></pre>
Buggy files: DWARF debuginfo generation, x86 heuristics tables, RS6000(?!) heuristic tables. I had to look up RS6000, it&#x27;s an IBM instruction set from the 90s lol. cp-tree.h is an interesting file, it seems be the main C(++) AST datastructures.<pre><code> 1017 gcc&#x2F;dwarf2out.c
 885 gcc&#x2F;config&#x2F;i386&#x2F;i386.c
 796 gcc&#x2F;cp&#x2F;cp-tree.h
 740 gcc&#x2F;config&#x2F;rs6000&#x2F;rs6000.c
 720 gcc&#x2F;cp&#x2F;pt.c
</code></pre>
*xfwm4*
Most changed files: the list is dominated by *.po localizations. I filtered these out. Even after this, I discovered there is very little active development in the last few years. If I extend to 4 years ago, I get:
1. src&#x2F;client.c - Realizing this project is too &quot;small&quot; to glean much from this. client.c is just the core X client management code. Makes sense.
2. src&#x2F;placement.c - Other core window management code.This has not told me much other than where most of the functionality of this project lies.Bus factor: Pretty huge. Not really an issue in this case due to lack of development I guess.<pre><code> 3298 Olivier Fourdan
 530 Anonymous
 319 Xfce Bot
 121 Jasper Huijsmans

</code></pre>
Files with bug commits: Very similar distribution to most changed files. Not enough datapoints in this one to draw any big conclusions.I think these massive open projects (excl xfwm) are generally pretty consistent code quality across the heavily trodden areas because of the amount of manpower available to refactor the pain points. I&#x27;ve yet to see an example of &quot;god help you if you have to change that file&quot; in e.g. linux, but I have of course seen that situation many times in large proprietary codebases.

Only two of the five insights are based on commit messages and the author acknowledges that they won&#x27;t work in projects without message discipline. But the remaining ones will give you valuable insights even into the most lazy project department.

I love how the commentator thinks a developer makes decisions based on commit messages.Random, subjective, or written in a state of mental exhaustion commit messages.I also love the switcheroo the author made: git not logs. But hey :)

&gt; AI generated commit messagesgit log --oneline and a sprinkle of your personal sauce on .claude goes a long way :)

And in every codebase I&#x27;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&#x27;t inline with traditional git scm, but it&#x27;s a very powerful workflow if you are OK with some hybridization.

I&#x27;ve seen it be the concatenated individual git commit messages way too often. Just a full screen scroll of &quot;my hands are writing letters&quot; and &quot;afkifrj&quot;. Still better than if we had those commits individually of course, but dear god.The gold standard is rebased linear unsquashed history with literary commits, but I&#x27;ll take merged and squashed PR commits with sensible commit messages without complaint.

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&#x27;s actually reviewed so tends to be much better I find.

I think it&#x27;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.

Yes, and a culture problem, too. I guess I&#x27;ve been blessed that I&#x27;ve mostly only worked for &quot;grown up&quot; companies, but I&#x27;ve never encountered a workplace where people didn&#x27;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 no big deal.If I joined a company where people committed their code with &quot;stuff&quot; or &quot;made some changes&quot; or &quot;asdfhlfo;ejfo;ae,&quot; that would be a red flag that I might have joined the wrong company, and I&#x27;d start to wonder what else the developers here do carelessly.

I once tutored an intern. Who thought he was The Best Programmer On Earth (didn&#x27;t we all at that age?). 
He refused to use revision control, it slowed him down.So we told him to commit at least once every day, with a relevant commit message, or else fail his internship.He worked 21 more days. There were 21 commits: &quot;17:00, time to go home&quot;.

I particularly love when the “CTO” is also the main offender.

One of the best developers I work with commits everything with the message &quot;changes&quot;(This is not an endorsement to do that, he&#x27;s a good developer in spite of his shitty commit messages)

It can be even enforced using hooks&#x2F;pipelines that will check that the message follow Conventional Commits as well

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

&gt; Even teams with terrible hygiene write &quot;fix&quot; when something breaks.They might not include anything but the Jira ticket number, if the environment is truly lacking.

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

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

I personally use git commit -m &quot;.&quot; for: &quot;Just snapshots this state real quick&quot; on a feature branch.main branch is advanced on PR level, with squashed commits.So the &quot;.&quot; should never make it to main, and have PR description as commit message.

git blame&#x27;s are amazing, and rely on good comments.

I read commit messages all the time to figure out what a change was about.For small personal projects I often write one phrase messages with `-m`, but if you&#x27;re working with other people you should be writing good commit messages.

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

&gt; my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentencesI have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality.e.g.- (a) chore: update some_module to include new_func- (b) feat: Add new_func to handle XYZ caseWhere:(a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles.(b) is using the correct &quot;feat&quot; commit type, capitalized and describe what this is for. I expect the body to explain &quot;why&quot;, as well, and not to reiterate the &quot;how&quot; in natural language.This is just my experience, but I&#x27;ve seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.

Our small team has a lot of commit messages like this. For a while, we had a guy on the team who had come from a site that expected more. The pet peeve he brought along was that commit messages end with a period (my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences). When I look at that period of development, I see lots of messages like “stuff changed.” And “more stuff changed.” And then it goes back to just “stuff changed” around the time they moved on.

Totally agree. One thing I really like about HN is it reminds you that nobody&#x27;s individual experience is indicative of the industry at large.The parent comment stated &quot;Most codebases I encounter just have &quot;changed stuff&quot; or &quot;hope this works now&quot;.&quot; I worked at 6 tech companies in my career and a slew of contracting gigs, and I literally never encountered the problem of commit messages being uninformative. Most of the companies developed strict rules for commit comments like always including an issue number (with occasional [NO-ISSUE] tags allowed for minor changes) or something like Conventional Commits, <a href="https:&#x2F;&#x2F;www.conventionalcommits.org&#x2F;en&#x2F;v1.0.0&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.conventionalcommits.org&#x2F;en&#x2F;v1.0.0&#x2F;</a> .

If developers don&#x27;t write commit messages, that&#x27;s a culture problem. At my company we demand that of each other.

Never seen that in any company I worked at either and I can’t believe professional developers seem to think that it would be ok to write meaningless commit messages. That’s just so sloppy.

&gt; It&#x27;s a small minorityIs it really a small minority? I have never worked on a project that didn&#x27;t have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright &quot;changed stuff&quot;).I don&#x27;t remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.

Commit messages are often squashed after merging a feature branch

Bad commit messages always fail PR review for me. It requires will and discipline, but it&#x27;s not that hard.

tbh I&#x27;m not convinced that a git log history should be treated as a group journal because it&#x27;s not.relying on git commit messages assumes they&#x27;re correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it&#x27;s just necessary to hit the save button real quick or move a workspace from one device to another.my point is: 
git is a way of storing and loading files at its core.

I think that&#x27;s pretty great, actually. You can look that up to see more info about the commit.

Sometimes it could be just a ticket number&#x2F;title

- fix
- fix fr
- fix frfr
- plz
- omg why
- never gonna give you up
- never gonna let you down
- add missing curly braces

Every time I hear about commit messages on HN, this is my first thought. I can&#x27;t imagine not working in a squash workflow. No matter how good your commit messages are, I do not want to read all of them. The squashed commit will direct me to the original PR in case I need more detail.

And in a squash and merge workflow, which are most teams I&#x27;ve been on the past 8 years, it really is the title of the pull request or merge request. That is what really matters.And I really like that because it leaves room to let the developer do whatever kind of commit messages they want to that makes sense to them. Because nobody&#x27;s really ever going to read those again after it squashed and merged.

I also like meaningful commit names. But am sometimes guilty of “hope this works now” commits, but they always follow a first fix that it turns out didn’t cut it.I work on a lot of 2D system, and the only way to debug is often to plot 1000s of results and visually check it behaves as expected. Sometimes I will fix an issue, look at the results, and it seems resolved (was present is say 100 cases) only to realize that actually there are still 5 cases where it is still present. Sure I could amend the last commit, but I actually keep it as a trace of “careful this first version mostly did the job but actually not quite”

We have a hard division between &quot;Core&quot; repos (those which are deployed to production &#x2F; customer sites) and everything else. The expectation in Core repos is that everything goes through a PR process where the pull request message is intended to explain the what and why of the change (perhaps with reference to a ticket, but with the key information restated in the PR), and goes through a review just like the code. Changes are then either squashed with that as the commit message or (if they&#x27;re larger and benefit from a clear separation of commits), may be rebased with `git rebase -i` assuming the final PR body ends up in one of the commit messages.Non-Core repos are absolute free-form anything goes. You can commit 8 times a day without a PR as long as you&#x27;re not deploying to production. This is excellent for things like test harnesses, CI&#x2F;CD nonsense, one-off experiments, demos, prototypes, etc.My last Core commit had something like 20 to 1 ratio between lines of commit message to lines of code (small change touching something deep that required a lot of explanation). My last non-Core commit message was &quot;hope this works&quot; (it did not).

Many organizations squash their commit messages from PR, where most commits actually happen. Unless everyone is committing to trunk all the time, which almost never happens on a real job, I highly doubt the value of this.Showing my Git ignorance here, of course - does &quot;ancestors(trunk)&quot; pull in all the commit messages?

&gt; developers write commit messagesThe people who don&#x27;t write commit messages for us are the non developers.Writing commit messages shouldn&#x27;t take any time at all. If it does, then you probably have a range of other professional issues.

One big problem about commit messages is, that you write them from your perspective. If you write them while activly engaged with the topic and changes you are very heavily biased and might miss things which are obvious to you but not to future readers with less knowledge. I think abstracting your personal opinion is quite hard - I agree that LLMs are perfectly fitting for writing this since they just dont have a &quot;personal opinion&quot;. Atleast I made the mistake in the past many times focusing on the things which were not obvious to me but then leaving out the non obvious things for others.

&gt; Most codebases I encounter just have &quot;changed stuff&quot; or &quot;hope this works now&quot;.I have been told off several times at different jobs for writing commit messages that are &quot;too big&quot;. Also for writing too much commentary in my code changes. Also also for complaining that other people aren&#x27;t doing these things.(Not that it stops me, mind, but it does make working relationships fractious.)

I do not approve PRs from junior devs until the commit message is useful.

Likely my own personal bias, but I have never once found git log&#x2F;commit messages to be useful when debugging or understanding what happened. I&#x27;m sure that others do so I try to write useful commits (conventional commits syntax is helpful here) but I&#x27;d much rather spend my time and effort understanding the current state of the codebase instead of trying to diagnose how &quot;fixed bug related to file naming&quot; relates to a website going down.

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 &quot;changed stuff&quot; or &quot;hope this works now&quot;.It&#x27;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 developers would actually use it (I hope they will).

I put it into a gist :)<a href="https:&#x2F;&#x2F;gist.github.com&#x2F;aeimer&#x2F;8edc0b25f3197c0986d3f2618f036f63" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;aeimer&#x2F;8edc0b25f3197c0986d3f2618f036...</a>

Dying or stabilizing?Most good projects end up solving a problem permanently and if there is no salary to protect with bogus new features it is then to be considered final?

For &quot;what changes the most&quot;, in my project it&#x27;s package.json &#x2F; lock (because of automatic dependency updates) and translation &#x2F; localization files; I&#x27;d argue that&#x27;s pretty normal and healthy.For the &quot;bus factor&quot;, there&#x27;s one guy and then there&#x27;s me, but I stopped being a primary contributor to this project nearly two years ago, lol.

I just finished¹ building an experimental tool that tries to figure out if a repo is slopware or not just by looking at it&#x27;s git history (plus some GitHub activity data).The takeaway from my experiment is that you can really tell a lot by how &#x2F; when &#x2F; what people commit, but conclusions are very hard to generalize.For example, I&#x27;ve also stumbled upon the &quot;merge vs squash&quot; issue, where squashes compress and mostly hide big chunks of history, so drawing conclusions from a squashed commit is basically just wild guessing.(The author of course has also flagged this. But I just wanted to add my voice: yeah, careful to generalize.)¹ Nothing is ever finished.

Nice! Will probably adopt this, seems to give a great overview!

superficial. If I have to unfuck the backend 10 times a week in our API adapter, then these commands will show me constantly changing the API adapter, although it&#x27;s the backend team constantly fixing their own bugs

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

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

I wouldn&#x27;t trust &quot;commit counts.&quot; The quality and content of a &quot;commit&quot; can vary widely between developers. I have one guy on my team who commits only working code that has been thoroughly tested locally, another guy who commits one line changes that often don&#x27;t work, only to be followed by fixes, and more fixes. His &quot;commits&quot; have about 1&#x2F;100th of the value of the first guy.

&gt; 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.”I&#x27;ve got my Emacs set up to display next to every file that is versioned the number of commits that file has been modified in (for the curious: using a modified all-the-icons-ivy-rich + custom elisp code + custom Bash scripts I wrote and it&#x27;s trickier than it seems to do in a way that doesn&#x27;t slows everything down). For example in the menu to open a file or open a recently visited file etc.: basically in every file list, in addition to its size, owner, permissions, etc. I also add the number of commits if it&#x27;s a versioned file.I like the fix&#x2F;bug&#x2F;broken search in TFA to see where the bugs gather.

Something something Red Queen&#x27;s race

Projects become more stable with time?  Since when?

&gt; I&#x27;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.&quot;Accelerating or Dying&quot; sounds like private equity&#x27;s lazy way to describe opportunity, not as a metric to describe software.

Technically you&#x27;re correct that change frequency doesn&#x27;t necessarily mean dead, but the number of projects that are receiving very few updates because they&#x27;re &#x27;done&#x27; is a fraction of a fraction of a percent compared to the number that are just plain dead. I&#x27;m certain you can use change frequency as a proxy and never be wrong.

Or you hired someone who squashes or doesn&#x27;t commit every single change.

Is it fair to say they are being &quot;worked on&quot; if nothing is being done?

That was my question too. I have plenty of projects I&#x27;ve worked on where they rarely get touched anymore. They don&#x27;t need new features and nothing is broken.

This is a neat trick for a quick visual presentation, thanks!

For this command in particular, one can add a cheap bar chart with awk:git log --format=&#x27;%ad&#x27; --date=format:&#x27;%Y-%m&#x27; | sort | uniq -c | awk &#x27;{printf $2&quot; &quot;; for (i=1;i&lt;=$1;i++){printf &quot;-&quot;;} print &quot;&quot;; }&#x27;

Bad memories at my former big tech company.Whenever we initiated a new (internal) SW project, it had to go through an audit. One of the items in the checklist for any dependency was &quot;Must have releases in the last 2 years&quot;I think the rationale was the risk of security vulnerabilities not being addressed, but still ...

Yeah, this one demonstrates a particularly pernicious view of software development. One where growth, no matter how artificial, is the only sign of success.If you work with service oriented software, the projects that are &quot;dying&quot; may very well be the most successful if it&#x27;s a key component. Even from a business perspective having to write less code can also be a sign of success.I don&#x27;t know why this was overlooked when the churn metric is right there.

&gt; Is This Project Accelerating or Dying
&gt;
&gt; git log --format=&#x27;%ad&#x27; --date=format:&#x27;%Y-%m&#x27; | sort | uniq -cIf the commit frequency goes down, does it really mean that the project is dying? Maybe it is just becoming stable?

This should be renamed to &quot;Git commands that I run as a new hire to get metrics I&#x27;ll forget on day 2&quot;.

I&#x27;m not saying more commits = bad developer. In my example that happened to be the case but not because they had a lot of commits but because they were bad at their job. I was just trying to warn that taking these git snippets at face-value does not paint the full picture.If someone came to me and said &quot;I ran these and I see XXX was the most prolific committer and they left X months ago, what will be do???&quot; I&#x27;d have to work hard not to laugh.Since these snippets are self-described as ways to get familiar with the code&#x2F;projects I wanted to provide the counter point. Most of those snippets do not at all paint the real picture and for all the repos I tested it on they paint the opposite of reality.I know these codebases like the back of my hand, the purported purpose of these snippets is to better understand the codebase, I can tell you they don&#x27;t work for anything I tested them on. Maybe they work for other codebases but the sample size I have access to says they don&#x27;t work for me.

So that person, on one central codebase at a company I work for, is me.Assuming I&#x27;m not ego-mad, I like to think this is because I built the project from the ground up before handing it over to the rest of the team.These days other people commit more often than I do, but my name is still dominant, and probably will be for some time.

Once word got out that a report was going up to a department head around commit frequency, a few of us started to make &quot;backup commits&quot; to boost our stats. Whether it be dev server config files (just in case!), local dev setups, whatever.. just something that changed enough on its own but would produce a steady stream of commits, while having some potential use case, however unlikely it was to actually be needed.Modern problems require modern solutions and all...

Also - be careful of automated workflow that uses a single persons credential.. skews this by a lot.

Everything in context. This is one of many reasons I&#x27;m a proponent of squash-and-merge. If a change really needs more than one permanent commit, it should probably be split up or if absolutely necessary should be on a feature branch maintaining similar process. Under this process, feature branches are not squashed.This leaves developers to commit locally and comment as much or little as they like.

Yeah. I am the top committer at my current workplace, but I&#x27;d say that a majority of that gap is because my particular workflow results in many smaller commits than my coworkers.

I think OP&#x27;s context is: they get called to help troubled projects. Often the people that hired them might not know where exactly the trouble comes from.If you look at a code base that&#x27;s not really in trouble, these commands don&#x27;t reveal the source of the trouble, because there might be none.

There&#x27;s some giveaways that it was too. &quot;It&#x27;s not x, its y.&quot;

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

Not to diminish your lived experience, but this is sort of a management issue, no?  There should be some expectations set and&#x2F;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&#x2F;history, others want the well-curated &quot;story&quot; with a bunch of squashes and rebases.

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&#x27;s handed when I was gone for two weeks.

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.&gt; git shortlog -sn --no-mergesIs the most egregious. In one codebase there is a developer&#x27;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 was a net-negative to the team in more ways than one, didn&#x27;t understand the codebase very well at all, and just happened to commit every time they turned around for some reason.

blog posts are just comments that would have been torn apart if only posted on a forum, now masquerading as important universal edicts

Git commands I run before reading any code