Git commands I run before reading any code
piechowski.io
piechowski.io
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
jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \
-T 'self.author().name() ++ "\n"' \
| sort | uniq -c | sort -nr
jj log --no-graph -r 'ancestors(trunk()) & description(regex:"(?i)fix|bug|broken")' \
-T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \
| sort | uniq -c | sort -nr | head -20
jj log --no-graph -r 'ancestors(trunk())' \
-T 'self.committer().timestamp().format("%Y-%m") ++ "\n"' \
| sort | uniq -c
jj log --no-graph \
-r 'ancestors(trunk()) & committer_date(after:"1 year ago") & description(regex:"(?i)revert|hotfix|emergency|rollback")'
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.
The most frequent "complex" 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'm not going to give agents my private key!)
jj log -r 'mine() & ~signed()'
# or if yolo mode...
jj sign -r 'mine() & ~signed()'
Does "own" try to sign working copy snapshot commits too? That would greatly increase the number and frequency of signatures.
> Does "own" try to sign working copy snapshot commits too?
Yes
If I change a line of code several times and rebase on to a branch that changed the same lines of code, how are you sure what the right one is?
However, the conflict algebra does remove many common uses of rerere. See https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... for a longer discussion.
Notice I didn't say "edit it, commit, and done" because that's another thing you don't do in jj - commit. I know, `git commit` is just a few characters on the cli - but it's one of several git commands you will never have to type again because jj does it without having to be asked.
If the rebase created a merge conflict (it could do so in any PR commit above the one you edited) - it's no biggie because jj happily saves merge commits with conflicts. You just check it out, and edit to remove the conflict.
Jj does grow on you over time. For example, when you start with jj you end up in the same messes you did as a git beginner, when you recovered with 'rm -r repository', followed by 'git clone git@host/repository.git'. Then you discover 'jj op restore' which compared to git's reflog is a breath of fresh air. And while you might at first find yourself chafing at the loss of git staging, you gradually get comfortable with the new way of working - then you discover `jj evolog`, and it's "omg that's far better than staging". Ditto with workspaces vs worktrees, and just about everything else. It might be difficult to lose work with a bad git command, but actually impossible to lose work with a jj command.
It is a steep learning curve. We are talking months to use it fluently instead of treating it as git with better porcelain. If all you ever do is work with one commit at a time, it's a lot of effort for not a lot of return. But as soon as you start managing stacks of changes, duplicating them, splicing them, it makes you feel like a god.
That said, if you are starting out - I'd suggest starting with jj instead of git. You've got to go through a learning curve anyway. You may as well do it with the kinder, gentler, more powerful tool.
That wouldn't be my advice if you're going to work with other people. You can't know jj without knowing git well enough to fall back in general
I don't use aliases, I guess I'm insane?
Also 99.9% of the time, git "just works" for me. If I need to do something special once a year, I can search for it. Like I would with jujutsu.
You can find this pattern again and again. How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?
For jujutsu, it's fine on your own computer, but you probably have to use git in the CI or on remote servers. And you probably started with git, so moving to jujutsu was an added effort (similar to dvorak).
That's not a problem, just switch to Qwerty when you use a different computer. For me at least, it's not hard at all to switch between Dvorak and Qwerty.
Sure, but you had to learn both. And what benefit did you get from learning Dvorak?
I feel the same with jujutsu: I have to learn it on top of git, and I don't see a lot of benefits from knowing it.
Same deal with jj vs. git. I've learned git. I've used it for 15 years. I'm proficient with it. I'm sure jj is better - but I'm not sure it's better enough to be worthwhile.
More comfortable typing, less wrist strain, etc. It's just a better layout.
Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist.
But that's not inherent to the keyboard. Linear switches are not any louder than cheapo office high-profile membrane.
There really isn't any reason not to choose one except for price - and that's a fair consideration if you're fine with rubber domes or other alternatives.
Low profile scissors are a compromise. They are tactile but it's for once functional as it compensates for the obvious lack of travel. The result is a mediocre but still above average experience. You can type fast on them but with more fatigue than high-profile linear.
Marketers want you to believe there's at least three different distinct switch types for different purposes because they want to sell you the same keyboard twice or thrice. But in reality there's linear and stupid. And some of them make unnecessary noise. Some of them make really sweet nostalgia noises like Alps switches but it's still a worse typing experience.
Gamers want mechanical keyswitches with no click at all. (Cherry brown I think)
The most popular type of switch is brown because it's essentially a linear switch that is not marketed towards gamers. It's just sad.
I don't get the mechanical keyboard one, though. I am fine with any keyboard, I just like my mechanical keyboard at home. Just like I am fine with any chair, but ideally I would have a chair I like at home.
120fps I have no experience with, but I would imagine it's closer to video quality. Once you're used to watching everything in 4K, probably it feels frustrating to watch a 1080p video. But when 4K did not exist, it was not a need. I actively try to not get used to 4K because I don't want to "create the need" for it :-).
I suggest not worrying too much about that - been using a big 4K TV with lots of 4K movies for a long time now and SD content is still as watchable as ever.
For framerates, especially in an interactive context, this is what happens though in my experience. But it also really depends what happens on screen - more movement needs higher framerates to feel smooth.
I love my Aeron chair. I've had it for fifteen years and it's still in great shape.
I used to have chronic back pain. Getting good ergonomics at home really put that to bed.
Those don't fit the others - they don't really require the user to adapt or are more complex in any way but are just nicer versions of the standard.
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'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't used it myself, but found it recently and thought it looked like a nice abstraction over raw Nix.
That's not been my experience with jj which after the initial hurdle is a breeze.
Disclaimer: I love jq too :)
`git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --`
Which is something I see a lot of people alias in Git for viewing logs.
If you remove the rainbow specification, it should be
git log --graph --pretty=format:'%h -%d %s (%cr) <%an>' --abbrev-commit --
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's effectively no other choice.
That said, the OP's commands are useful, I am copying them (because obviously I won't ever memorize them).
https://github.com/denisidoro/navi
But for Git, I can't recommend lazygit enough. It's an incredible piece of software:
I wrote a cheat sheet in my notes of common commands, until they stuck in my head and I haven't needed it now for a decade or more. I also lean heavily on aliases and "self-documenting" things in my .bashrc file. Curious how others handle it. A search every time I need to do something would be too much friction for me to stand.
FWIW i use Claude to help with code changes, then give the diff to Gemini to review/ create meaningful commit messages
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
I am the same way, and have caught much flack for it over the years.
But when I sit down at a foreign system (foreign in the sense that I haven't used it before) because something is broken and my help was requested, I don't have any need to lean on aliases.
I worked with someone once that had a very impressive bashrc, and it was very effective for them... on their workstation. Plop them in front of a production system, they can't even remember how to remount / rw because they've been using an alias for so long.
This is also why I learned vi, having started with emacs 30 years ago initially, as it was first taught to me. I know it'll be there, and I know how to use it.
What I resent is someone telling me how to use a computer. I've got that bit mostly down at this point.
Yes! We mostly wouldn’t tolerate the complexity and the terrible UX of a tool we use everyday--but there's enough Stockholm Syndrome out there where most of us are willing to tolerate it.
Git may be sharp and unwieldy, but it's also one of the decreasing amount of tools we still use - the trend of turning tools into toys consumed the regular user market and is eating into tech software as well.
Git is NOT that.
Git is something you use to get stuff done, until it becomes an irritating obstacle course of incidental complexity.
To me, it's more like GitHub won; Git came along for the ride.
Back in the day when companies evaluated Git and Mercurial (Facebook, Google, Microsoft), they decided Mercurial was better. Mozilla used Mercurial for a long time until switching to Git fairly recently.
But once GitHub took off and became the center of gravity for developers, it became the de facto standard.
It also explains why there have been several attempts (Sapling, JJ) to use Mercurial's semantics as a front-end for Git.
FWIW I too was once a "memorised a few commands and that was it" type of dev, then I read 3 chapters of the Git book https://git-scm.com/book/en/v2 (well really two, the first chapter was a "these are things you already know") and wow did my life with git change.
No, various other tools used it before git, e.g. openssl.
Because `checkout` is for getting the working directory to the state of a specific revision. Which both means switching branches (which are just pointer to revisions) and clearing changes (and get back to the starting revision). In both cases, you "check out" the version of the file at a specific commit or HEAD.
Partly that, but for me at least, I have a bunch of simple bash scripts and aliases for things I do frequently. Git makes this really easy because you can set aliases for lots of custom commands in the .gitconfig file.
We can't.
Why do you think the `man` command exists?
If you have multiple machines (/must have), just apply your user config to current machine?
Or, perhaps better yet, defining your own functions/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).
Don't feel bad - no one remembers them all, we just remember a few idioms we use...
# output each value in the array separately
.[]
# output each value but transform it in some way
.[] | . * 2
# map each value into a new array
map(. * 2)
# same as above but manual iterate/collect
[.[] | . * 2]But jq I use maybe once a week, and it just won'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).
And yes, I'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 "things I do at least every week or two" and "things that make me reach for the git book every single time".
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.
and when a new branch is one key stroe away from being created, I am more inclined to use it.
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 updated
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 bug reports).
A QR (or barcode) library is exactly the type of thing I’d assume would still work fine, since there’s nothing new to do, the parsing rules don’t change, it’s a static, known, solved problem.
I agree with you - and yet the barcode library I used recently for a variable-data-printing project was last updated 13 hours ago, despite having been around since 2008!
Agreed. 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.
> 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.
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.
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.
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 developers would actually use it (I hope they will).
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 :)
git log --oneline and a sprinkle of your personal sauce on .claude goes a long way :)
I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.
One minor nuisance that can come up with GitHub in particular when using a short reference like #123 is that that link breaks if the repo is forked or merged into something else. For that reason, I try to give full-url references at least when I'm manually inserting them, and I wish GitHub would do the same. Or perhaps add some hidden metadata to the merge commit saying "hey btw that #123 refers to <https://github.com/fancy-org/omg-project/issues/123>"
Yeah I usually default to just a straight up link or a markdown link. Mostly because I usually don’t know the exact number of a PR/ticket/issue - so it’s easy to just copy the URL once I’ve found it.
The gold standard is rebased linear unsquashed history with literary commits, but I'll take merged and squashed PR commits with sensible commit messages without complaint.
To the point of other commenters however, I wouldn't lay something this micro at the foot of the CTO in all but the smallest of organizations.
In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a furious pace to keep their particular section of the business happy. We're lucky enough that they spun up their own repo to do their work on, so they don't actually impact other teams, but if the quality of the commit messages is anything to go by, I am 100% certain they're going to end up in a huge mess, if they aren't already. The team lead encourages this, and certainly doesn't care about commit messages etc.
Developers who care about other developers tend to write better quality code, because they care what other developers think of them. If you care about other developers, you will most likely write decent quality commit messages too.
I have seen over many years the types of developers who only care about moving their own code into production as fast as possible and getting to the next thing. There is a very high correlation with a mess at the end, which they inevitably won't have to tidy up because they'll be doing the next thing. These types of developers hate owning stuff in production, so they don't do it, so they don't actually care how maintainable their "clever" code is. I am very certain that a number of people reading this will be those types of developers.
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.
As a manager, one of the first things I do is make sure that the PR titles (the PR text becomes the commit messages in squash-merging workflows) at minimum begin with a ticket number. Then we can later read both the intention and the commentary on it.
Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.
And for old enough code, the author may not be available, or more likely doesn't remember.
It feels like we're trying really hard to stretch the utility of commit messages here...
I don't feel that is an accurate statement for any complex system.
1. What project in general the change was associated with (it may not be obvious from the files changed in this single commit) which can indeed tell you how well it was spec’d- maybe you’ll even find the technical plan.
2. Possibly a hint of how the author intended it to work, or a clue about their misunderstanding. For example, the commit may have changed a function to accept a null argument to “solve” some other problem, but now you know that null passing through here is harmful, well thanks to the commit info, you know that you have to account for the problem that dev was “solving” if you don’t allow the null here. Without that you’d just revert the change and cause the other bug to regress.
Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.
> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.
If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.
Links to ticket IDs are good, and good leaders don’t let old ticket links break on bugtracker migration.
A sentence or so to let future devs know what this change meant to do or at least what initiative it was intended to support, is also good. If future devs (even future YOU) don’t know what you were trying to do, they might revert a change which, without context, looks like a mistake.
Doing both ticket link + text is ideal because someone might screw up the ticket system, and a sentence on its own can be ambiguous.
Doing neither, on purpose, is just willful stupidity. Don’t even bother with Git if you want your commits, the ones that end up in “dev” I mean, to all just say “wip,” “asdf,” and “hope it works now.”
You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.
Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?
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 challenging
* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature
then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.
I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]
> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop
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. We'd expect the same from a competent carpenter or cook.
[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=log
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[2] https://git.ffmpeg.org/gitweb/ffmpeg.git/log
[3] https://github.com/openjdk/jdk/commits/master/src/hotspot
[4] https://github.com/openssl/openssl/commits/master/
[5] https://spinroot.com/gerard/pdf/P10.pdf The Power of Ten - Rules for Developing Safety Critical Code
This is classic dogmatics over pragmatics.
The carpenter understands how to use every tool, they are just pragmatic about its use.
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.
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=...
They are useless: Google Messages bothers me to upgrade to a new version. I read the changelog: "Bug fixes and performance improvements". Last time they did it it was full of bugs. Really Google: come back when you actually fixed something.
If I joined a company where people committed their code with "stuff" or "made some changes" or "asdfhlfo;ejfo;ae," that would be a red flag that I might have joined the wrong company, and I'd start to wonder what else the developers here do carelessly.
To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.
A week? LUXURY. I'd be happy to get PRs approved without a week of fighting over stupid trivial nonsense[0]
[0] [flashbacks to the "which way of defining Perl constants is faster" week of hell]
These things never take much time but people dismiss them because of that. Because each commit and each comment in isolation isn't very valuable but they are very helpful in aggregate. I'm not sure why this bias exists though, since the same is true for lines of code. It's also true about a ton of things. All the little things add up. Just because it's little now doesn't mean it's not important
More likely you'd already know by this point because it would be staring you in the face
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: "17:00, time to go home".
The problem was, as I mentioned, "he though he was the best developer ever". stubborn as hell. And pushed back against anything he wasn't used to, anything that wasn't his usual "ssh or ftp into prod and change stuff until it works" because he thought this was the only method that worked.
This was my first encounter with a self-proclaimed "10x" developer before that term existed. Someone who - as seen by far off management - seemingly have a high output, but in reality just create a trail of tech-debt and work for the rest of the team.
The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits.
And all this of course was when I was still able to keep on top of the massive volume of change. With AI that's simply no longer the case and the volume of change is only going to increase over time. Human reviews are now the main bottleneck to getting code merged. AIs probably should be doing a lot of the reviewing, gatekeeping testing, vetting, etc. Especially when AIs also produce most of the change. It's likely a lot of things will slip through unless you get your house in order on guard rails and process that your AI agents need to follow. As a CTO, guarding quality without becoming a human bottleneck is now the main challenge and removing bottlenecks responsibly is part of the job.
BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
Why do you think OSS projects have a high bar for change descriptions? It's because some things matter for the long run.
Also, it's pretty clear from the context of this discussion that it's about the descriptions on pull requests (or other units of change like CLs) and not individual commits that get squashed in a PR/CL.
> BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
All coding agents do that these days - they just run git diff and figure out what the change is when writing the commit message. Are you saying that writing a better change description is not worth the pennies it costs in tokens?
sound like something maybe good commit messages could help with
(This is not an endorsement to do that, he's a good developer in spite of his shitty commit messages)
So, before AI came and saved me from writing commit messages I had alias that ran the whole git add . && git commit -m ... && git push with a fixed commit message. But of course we had squashing so PR title was the one to eventually go there, so maybe that part is fine. But all my side projects had just that.
But I use magit and I can commit specific lines and hunks as easily as files. That helps with managing changes to meaningfully group them.
That's fine until you come up against something like a subscription system that's been built over 15 years by at least 20 different developers, none of whom are currently at the company, half of whom appear to have been clinically insane, each of whom had their own unique approach to code, with almost zero code commentary, zero external documentation, and abstractions layered like geological strata where you need 15 files open to understand one API endpoint.
I though we were talking about good commit messages.
They might not include anything but the Jira ticket number, if the environment is truly lacking.
main branch is advanced on PR level, with squashed commits.
So the "." should never make it to main, and have PR description as commit message.
For small personal projects I often write one phrase messages with `-m`, but if you're working with other people you should be writing good commit messages.
I 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 case
Where:
(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 "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language.
This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.
The parent comment stated "Most codebases I encounter just have "changed stuff" or "hope this works now"." 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, https://www.conventionalcommits.org/en/v1.0.0/ .
Is it really a small minority? I have never worked on a project that didn't have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright "changed stuff").
I don't remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.
relying on git commit messages assumes they're correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it'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.
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's really ever going to read those again after it squashed and merged.
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”
Non-Core repos are absolute free-form anything goes. You can commit 8 times a day without a PR as long as you're not deploying to production. This is excellent for things like test harnesses, CI/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 "hope this works" (it did not).
Showing my Git ignorance here, of course - does "ancestors(trunk)" pull in all the commit messages?
The people who don't write commit messages for us are the non developers.
Writing commit messages shouldn't take any time at all. If it does, then you probably have a range of other professional issues.
I have been told off several times at different jobs for writing commit messages that are "too big". Also for writing too much commentary in my code changes. Also also for complaining that other people aren't doing these things.
(Not that it stops me, mind, but it does make working relationships fractious.)
> 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 was a net-negative to the team in more ways than one, didn't understand the codebase very well at all, and just happened to commit every time they turned around for some reason.
Assuming I'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.
If someone came to me and said "I ran these and I see XXX was the most prolific committer and they left X months ago, what will be do???" I'd have to work hard not to laugh.
Since these snippets are self-described as ways to get familiar with the code/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'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't work for me.
Modern problems require modern solutions and all...
This leaves developers to commit locally and comment as much or little as they like.
If you look at a code base that's not really in trouble, these commands don't reveal the source of the trouble, because there might be none.
As you identified there is a lot of parallel sentence structure.
They also have a bunch of lists of 3-5 items which is a classic.
It doesn't have the anodyne rambling never getting to the point style common to LLMs
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 two weeks.
[alias]
st = status
ci = commit
co = checkout
br = branch
df = diff
dfs = diff --stat
dfc = diff --cached
dfh = diff --histogram
dfn = diff --name-status
rs = restore
rsc = restore --staged
last = log -1 HEAD
lg = log --graph --decorate --oneline --abbrev-commit
cm = commit -m
ca = commit --amend
cane = commit --amend --no-edit
who = shortlog -sn --no-merges HEAD
dmg = log --oneline -i -E --grep='(incident|outage|downtime|rollback|revert|mitigate|mitigation|hotfix|broke|prod)' --since='1 year ago'
bugs = log --oneline -i -E --grep='(bug|bugfix|fix|fixed|fixes|defect|regression|hotfix|broke)' --since='1 year ago'
bugfiles = !git log --name-only --format='' -i -E --grep='(bug|bugfix|fix|fixed|fixes|defect|regression|hotfix|broke)' --since='1 year ago' | sort | uniq -c | sort -nr
monthly = !git log --since='1 year ago' --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
churn = !git log --format='' --name-only --diff-filter=AM --since='1 year ago' | sort | uniq -c | sort -nr | head -20The most changed file is the one people are afraid of touching?
Generation is precompilation.
Entry point is interesting. Lots of scope to become a scary file.
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”.
I’m not sure why HN attracts this need to poke holes in interesting observations to “prove” they aren’t actually interesting.
Very different from just counting commits - https://vectree.io/c/delta-compression-heuristics-and-packfi...
Nobody is afraid of changing it.
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' call "to rewrite the app from scratch" 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.
otherwise you're right, it could be a long linear list of appends where people are happy to contribute.
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.
git log -i -P --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | gsort -nr | head -20
# summary: print a helpful summary of some typical metrics
summary = "!f() { \
printf \"Summary of this branch...\n\"; \
printf \"%s\n\" $(git rev-parse --abbrev-ref HEAD); \
printf \"%s first commit timestamp\n\" $(git log --date-order --format=%cI | tail -1); \
printf \"%s latest commit timestamp\n\" $(git log -1 --date-order --format=%cI); \
printf \"%d commit count\n\" $(git rev-list --count HEAD); \
printf \"%d date count\n\" $(git log --format=oneline --format=\"%ad\" --date=format:\"%Y-%m-%d\" | awk '{a[$0]=1}END{for(i in a){n++;} print n}'); \
printf \"%d tag count\n\" $(git tag | wc -l); \
printf \"%d author count\n\" $(git log --format=oneline --format=\"%aE\" | awk '{a[$0]=1}END{for(i in a){n++;} print n}'); \
printf \"%d committer count\n\" $(git log --format=oneline --format=\"%cE\" | awk '{a[$0]=1}END{for(i in a){n++;} print n}'); \
printf \"%d local branch count\n\" $(git branch | grep -v \" -> \" | wc -l); \
printf \"%d remote branch count\n\" $(git branch -r | grep -v \" -> \" | wc -l); \
printf \"\nSummary of this directory...\n\"; \
printf \"%s\n\" $(pwd); \
printf \"%d file count via git ls-files\n\" $(git ls-files | wc -l); \
printf \"%d file count via find command\n\" $(find . | wc -l); \
printf \"%d disk usage\n\" $(du -s | awk '{print $1}'); \
printf \"\nMost-active authors, with commit count and %%...\n\"; git log-of-count-and-email | head -7; \
printf \"\nMost-active dates, with commit count and %%...\n\"; git log-of-count-and-day | head -7; \
printf \"\nMost-active files, with churn count\n\"; git churn | head -7; \
}; f"
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.)
In my experience, when the team doesn'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.
If the commit frequency goes down, does it really mean that the project is dying? Maybe it is just becoming stable?
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.
I know people win the lottery every week, but I also believe that buying a lottery ticket is essentially the same as losing. It's the same principle.
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c | awk '{printf $2" "; for (i=1;i<=$1;i++){printf "-";} print ""; }'
If you work with service oriented software, the projects that are "dying" may very well be the most successful if it's a key component. Even from a business perspective having to write less code can also be a sign of success.
I don't know why this was overlooked when the churn metric is right there.
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 "Must have releases in the last 2 years"
I think the rationale was the risk of security vulnerabilities not being addressed, but still ...
Another one I do, is:
$alias gss='git for-each-ref --sort=-committerdate'
$gss
ce652ca83817e83f6041f7e5cd177f2d023a5489 commit refs/heads/project-feature-development
ce652ca83817e83f6041f7e5cd177f2d023a5489 commit refs/remotes/origin/project-feature-development
1ef272ea1d3552b59c3d22478afa9819d90dfb39 commit refs/remotes/origin/feature/feature-removal-from-good-state
c30b4c67298a5fa944d0b387119c1e5ddaf551f1 commit refs/remotes/origin/feature/feature-removal
eda340eb2c9e75eeb650b5a8850b1879b6b1f704 commit refs/remotes/origin/HEAD
eda340eb2c9e75eeb650b5a8850b1879b6b1f704 commit refs/remotes/origin/main
3f874b24fd49c1011e6866c8ec0f259991a24c94 commit refs/heads/project-bugfix-emergency
...
Also, very tangentially, to the notion of the Developer's Legacy Index: https://www.javaadvent.com/2021/12/using-jgit-to-analyse-the...
The grep for bugs is not particularly comprehensive: it will pick up some things that aren't bugs, and will miss a bunch of things too.
The "project accelerating or dying" seems odd to me. By definition, the bulk of commits/changes will be at the very beginning of history. And regardless, "stability" doesn't mean "dying".
Let's NOT jump to conclusions; it could mean many things. For example, a period with other priorities, different urgencies, other issues external to the project itself and beyond our control, vacations, illnesses, or anything else that could impact the commit history.
I think these considerations and the others expressed in this article can easily lead to hasty conclusions and erroneous deductions, too simplistic.
Coding flow, like business needs, cannot always be objectively and deterministically measured.
git clone --depth 1 --branch $SomeReleaseTag $SomeRepoURL
If you only want to build something, it only downloads what you need to build it. I've probably saved a few terabytes at this point!
> How Often Is the Team Firefighting
> git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback
> Crisis patterns are easy to read. Either they’re there or they’re not.
I disagree with the last two quoted sentences, and also, they sound like an LLM.
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?
This list is also one of many arguments for maintaining good Git discipline.
For the "bus factor", there's one guy and then there's me, but I stopped being a primary contributor to this project nearly two years ago, lol.
Well isn't it typical that the person who wrote is also the person that merged? I have never worked in a place where that is not the norm for application code.
Even if you are one of those insane teams that do not squash merge because keeping everyone's spelling fixes and "try CI again" commits is important for some reason, you will still not see who _wrote_ the code, you will only see who committed the code. And if the person that wrote the code is not also the person that merges the code, I see no reason to trust that the person making commits is also the person writing the code.
Spend time educating your team about `git commit --amend` and `git push --force` on their own branches and you don't have to see any of that ugliness.
1. I don’t have to see that ugliness. 2. Nobody has to force push and micro manage commits.
If I recall correctly most code forges will add co-author trailers if someone other than the author squash merges.
I'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's trickier than it seems to do in a way that doesn'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's a versioned file.
I like the fix/bug/broken search in TFA to see where the bugs gather.
The takeaway from my experiment is that you can really tell a lot by how / when / what people commit, but conclusions are very hard to generalize.
For example, I've also stumbled upon the "merge vs squash" 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.
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 whether the squashed patchset consisted of commits with multiple authors (and even then you could store it with Co-authored-by trailers, but that's harder to use in such oneliners).
With a squash merge one PR is one commit, simple, clean and easy to roll back or cherry-pick to another branch.
it's hard to say fully, but unless a changeset is quite small or otherwise is basically 0% or 100%, there are usually smaller steps.
like kind of contrived but say you have one function that uses a helper. if there's a bug in the function, and it turns out to fix that it makes a lot more sense to change the return type of the helper, you would make commit 1 to change the return type, then commit 2 fix the bug. would these be separate PRs? probably not to me but I guess it depends on your project workflow. keeping them in separate commits even if they're small lets you bisect more easily later on in case there was some unforseen or untested problem that was introduced, leading you to smaller chunks of code to check for the cause.
I've never considered how an engineer approaches a problem. As long as I can understand the fundamental change and it passes preflights/CI I don't care if it was scryed from a crystal ball.
This does mean it is on the onus of the engineer to explain their change in natural language. In their own words of course.
I might have not stated my position correctly. When I mean "squash on merge", I mean the commit history is fully present in the PR for full scrutiny. Sometimes commits may introduce multiple changes and I can view commit ranges for each set of changes. But it takes the summation of the commits to illustrate the change the engineer is proposing. The summation is an atomic change, thus scrutinizing terms post-merge is meaningless. Squashing preserves the summation but rids of the terms.
Versioned releases on main are tagged by these summations, not their component parts.
The primary value of commit history comes from blame, bisect and corresponding commit messages. There's no reason to "treat PRs as atomic changes to the code base", commits are already supposed to be that and PRs are groups of commits (sometimes groups of size 1, but often not).
> When I mean "squash on merge", I mean the commit history is fully present in the PR for full scrutiny.
And when you merge the set of commits prepared by the author for review in, you get both "summations" and individual commits stored in the commit graph (where their place is) and you get to choose which way you want to view them at retrieval time without having to dig up things outside of the repository. Sometimes it's useful to see the summations only ("--first-parent"), sometimes you only want the individual atomic changes ("--no-merges"), sometimes you want to see them all but visually grouped together for clarity ("--graph"). When you squash on merge, you just give all that flexibility away for no good reason.
It's a commit graph, not a commit linked list, so treat is as such.
And here's a slightly smaller one which isn't about "miscellaneous fixes": https://lore.kernel.org/netdev/20260408122027.80303-1-xuanzh...
Some of these commits even get reviewed by different maintainers before being merged, which is common when a patchset touches several subsystems at once.
Then I must be a bad reviewer. In a past job, I had a colleague who meticulously crafted his commits - his PRs were a joy to review because I could go commit by commit in logical chunks, rather than wading through a single 3k line diff. I tried to do the same for him and hope I succeeded.
I think in most teams I've worked with, the majority of developers (> 85%) barely undestand what Git is doing or what things mean inside GitHub, have never seen commit history as a graph, have never run something like "git log --oneline --graph --decorate" or "--format", and have never heard of "git range-diff" which is very useful for following commit/PR/unit changes.
Personally I review using "git" itself, so I see the graph structure either way, and there's little difference between stacked PRs, commit chains in a single PR, or even feature branches, from that point of view. Even force-push branch updatea aren't difficult to review, because of the reflog and "git range-diff". The differences are mainly in what kinds of behaviour the web-based tooling promotes in the rest of the team, which does matter, and depends on the team.
I agree with you if you're using Graphite instead of GitHub. Having a place to give feedback and/or approval on the individual "units" (commits in a PR, or PRs in a stack) is useful, grouping dependent but distinct changes is useful, and diff'd commit evolution within each unit PR in response to back-end-forth review feedback is useful in some collaborative settings. Though, if you know "git range-diff" and reflog, that shows diff'd commit evolution quite well.
In GitHub, people are confused by stacked PRs both conceptually and due to the GitHub UX around them. Most times when I've posted a stacked PR to a GitHub project, other people didn't realise it was stacked, and occasinally someone else has merged the tip of a stack made by me, and been surprised to see all the dependent PRs merged automatically as a side effect. Usually before they get to reviewing those other PRs :-)
People understand commit sequences in a PR, though I've rarely seen people treat the individual commits as units for review when using GitHub, unfortunately. In the Linux kernel world where Git was born, the PR flow is completely different from GitHub: Their system tends to result in feedback on individual commits. It also encourages better quality feedback, with less nitpicking, and better quality commits.
I feel like what you're arguing is that you should clean up your commits before anyone else sees them. Fair. But you could also clean it up right before merging to main. It's not that different, except the latter is much less annoying, particularly when going back and forth with people.
I know this is a very github centric workflow, but that's where most engineers work now, and it's nice and easy. This wouldn't work for eg: contributing to linux, but that's not what most of us do.
Not often, but given that it costs me nothing to have it all in my tree, I'd rather have it than not.
I meant "shared place" as an open review request or a shared branch rather than shared underlying infrastructure. Shared by people's minds.
It just feels wrong to force push, destroying stuff that used to be there.
And I don't have the time or energy to bisect through my shitty PR commits and combine them into something clean looking - I can just squash instead.
Things that aren't referenced by anything anymore will eventually get garbage collected and actually destroyed, but you can just keep a reference somewhere to prevent that from happening if you need. Or even disable garbage collection completely.
Looks like people's fears about git come just from not knowing what it does.
You can often also access equivalent functionality by platform APIs. For example, GitHub has event API which you can use to check what a ref has pointed to previously.
1. Open PR page in whatever tool you're using
2. Read title + description to see what's up
3. Swap to diff and start reading through the changes
4. Comment and/or approve
I've never heard anyone bothering to read the previous commit messages for a second, why would they care?
Having atomic commits lets you actually benefit from having them. Suddenly you don't have to perform weird dances with interconnected PRs with dependencies as "PR too big" is not such a problem anymore as long as commits are digestible; you can have things property bisectable; you can preserve shared authorship; you can range-diff and have a better view on what and how changed between review passes, and so on...
The unit of change is commit, and PRs group commits you want someone to pull. If you don't want or need any of that, you're just sending a patch file in a needlessly elaborate way.
This is in fact what hg does with amending changesets and yes it works far better. Keep PRs small and atomic and you never need to worry about what happens intra-pr. If you need bigger units of work that's what stacking is for.
A PR is a group of commits, just utilize that when you need it.
this forces the reviewer to view the entire diff at once, which can greatly increase the cognitive load vs. being able to view diffs of logical units of work
for tiny PRs it may not matter, but for substantial PRs it can matter a lot
* A method or function that has code you realize needs to be shared...the code may need to be moved and also modified to accommodate its shared purpose. Separating the migration from any substantive modifications allows you to review the migration commit with the assistance of git's diff.colorMoved feature. It becomes easier to understand what changes are due to the migration, and what changes were added for more effective sharing.
* PRs sometimes contain mechanical work that is easy to review in isolation. Added or removed arguments, function renames, etc. No big deal if it's two or three instances, but if it's dozens or hundreds of instances, it's easier for the humans to review all of those consistent changes together, rather than having them mixed in with other things one has to reason about.
* Sometimes a flow of commits can help follow a difficult chain of reasoning. PR developer claims that condition X can never occur, but the code is complex enough that it's difficult to verify. However, by transforming the code in targeted ways that are possible to reason about, the complexity might be reducible to the point where the claim becomes obvious. One frequent example I see of this is of function/method arguments that are actually unnecessary, but it wasn't obvious until after some code transformations.
For other cases, you lose the information about why things are this way. It's too verbose to //comment on every like with how it came to be this way but on (non-rare in total, but rare per line) occasion it'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 >1 person worked on a feature branch, which I'd say is common)
I use it like that too and yet the reviewers don't get to see these commits. Git has very powerful tools for manipulating the commit graph that many people just don't bother to learn. Imagine if I sent a patchset to the Linux Kernel Mailing List containing such "fix typo", "please work now", "wtf" patches - my shamelessness has its limits!
I simply commit something like "WIP: testing xy" and if its working and properly implemented i can squash/rebase/edit the commit message and force push it to my feature branch. Using a Git client like Gitkraken makes this incredibly easy, takes seconds.
This way I can leverage version control without committing bogus states to the final PR.
When I work on something, I commit often and use the commit graph as a undo tool on steroids. I can see what I tried, I can cherry-pick or revert stuff while experimenting, I can leave promising but unfinished stuff to look at later, or I can just commit to have a simple way to send stuff to CI, or a remote backup synced between machines.
Once I'm done working on something, it's time to take a step back, look at the big picture, see how many changes my experiments have actually yielded, separate them, describe and decide whether they go to review together or split in some way, as sometimes working on a single thing requires multiple distinct changes (one PR with multiple commits), but sometimes working in a single session yields fixes for multiple unrelated issues (several PRs). Only then it gets presented to the reviewer.
It just happens that I can do both these distinct jobs with a single tool.
Can you explain to me what an avid squash-merger puts into the commit message of the squashed commit composed of commits "argh, let's see if this works", "crap, the CI is failing again, small fix to see if it works", and "pushing before leaving for vacation" ?
Usually pretty close to what the PR title + description are actually, just without the videos and screenshots.
Example:
feat(ui): Add support for tagging users
* Users can be tagged via the user page * User tags visible in search results (configurable)
etc..
I don't need to spend extra time cleaning up my git commits and force-pushing on the PR branch, losing context for code reviews etc. Nor does anyone have to see my shitty angry commits when I tried to figure out why Playwright tests ran on my machine and failed in the CI for 10 commits.
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'd be frustrated if people were committing messages like that.
Personally I'm a "one commit" type of guy, I don'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'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's computer died or similar. I found that silly at the time and still do now. That's what backups are for, I dislike when people use git as a backup like that in a professional setting.
But even if you don't, you're just one command line parameter away from making bisect behave exactly as if you had squashed them should you need it.
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.
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 "stupid" without any nuance.. well that's "stupid" :)
Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.
The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.
In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.
There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.
Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.
* git merge ALWAYS does a merge and git pull ALWAYS does a fast forward.
* git log --first-parent is the default. Have a git log --deep if you want to go down into branches.
I set merge.ff = false and alias ff to merge --ff-only. I don't use pull but I do have pull.ff = only set, just in case someday I do.
The graph log and the first-parent log serve different purposes and possibly shouldn't be the same command conceptually; this varies by user preference but the first-parent log is more of a "good default", generally. Merges do say "Merge" at the start, after all.
This is what I advise people to do in consulting engagements, too, it's not one of my personal quirks.
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.
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'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
I'd say that optimizing for reviewers who don't know "git range-diff" exists has even less merit that optimizing for contributors who don't know how to edit their commit graph.
I'm regularly using GitHub, GitLab, Gerrit, Phabricator and mailing lists and while some make it more pleasant than others, none of them really put any actual obstacles on your path when manipulating the commit graph mid-review.
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.
I think this is all Github's fault, in the end, but I think we need to get Github to change and until then will keep using squash-merges.
The cases where bisect fails you are, basically, ones where it lands on a merge that does too much - you now have to manually disentangle the side that did too much to find out exactly what interaction caused the regression. But this is on the rarer side because it's rare for an interaction to be what caused the regression, it's more common that it's a change - which will be in a non-merge commit.
The squash merge workflow means every single commit is a merge that does too much. Bisect can't find anything useful for you by bisection anymore, so you have to get lucky about how much the merge did, unenriched by any of the history that you deleted.
They're not noise, they tell future maintainers why something is the way it is. If it'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.
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.
(and if you hadn't squashed on merge, short-lived branches wouldn't even "disappear" in the first place as you would still see them decorated in "git log" on commits that were merged in)
If you've worked on a large team without squashing and without increasing frustration I'd be greatly interested to hear about it.
and it touches in detail what exactly commit standards should be, and even how to automate this on CI level.
And then I also have idea/vision how to connect commits to actual product/technical/infra specs, and how to make it all granular and maintainable, and also IDE support.
I would love to see any feedback on my efforts. If you decide to go through my entire 3 posts I wrote, thank you
What a weird check and assumption.
I mean, surely most of the "20 most-changed files" will be README and docs, plus language-specific lock-files etc. ?
So if you're not accounting for those in your git/jj syntax you're going to end up with an awful lot of false-positive noise.
You're right about package.json, pnpm-lock etc though, but those are easy to filter out if the project in question uses them.
You'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 ....
This post is about exploring code, not documentation. Nobody is going to warn you about the README unless it is super outdated.
That probably isn’t a good sign
Plus, adding an extra point: When you run git log --oneline --graph and the pattern on the left is more complex than the Persian carpet patterns or Ancient Egyptian writings in the Great Pyramid of Giza, you know it's engineering & process quality issue than the code itself...
Of course the two most useful ones would never be useful in the code base I am currently working on.
"fix" might be the single most common commit message, and after that comes "."
Trying for two years, to get people to include at least some information in their commit messages, has exhausted me.
Anyway, I can glean a lot of this information in a few minutes scrolling through and filtering the log in magit, and it doesn't require memorizing a bunch of command line arguments.
For most, I added some filters and slightly changed the regex, and it showed the reality of the codebase (I already knew the reality, I just wanted to see if it matched, and it did).
On main:
2020-01-01: "Changes"
2020-01-05: "Changes"
2020-01-06: "merge <ref to jira/gh issue>"
2020-01-07: "revert <ref to unrelated jira/gh issue from 2 yrs ago>"
Then there’s the people that include merge commits despite agreeing on rebasing.
Occasionally see sprinkles of decent, consistently formatted commit messages.
I think this is only useful on medium to large _open source_ projects. Clearly established CONTRIBUTING.md/README.md and commit formatting/merging guide.
https://gist.github.com/aeimer/8edc0b25f3197c0986d3f2618f036...
I abhor squash merging for this and a few other reasons. I literally have to go out of my way to re-check out a branch. Someone who wants to use my current branch cannot do so if I merge my changes a month later, because the squash rewrites history, and now git is very confused. I don't get the obsession with "cleaning up the history" as if we're all always constantly running out of storage over 2 more commits.
And GitHub at least sets the author of the squashed commit as the one who opened the PR, not the one who merged it.
I can definitely see where it wouldn't work well for other workflows but I've had it work well on several teams and it seems easier than trying to get everyone to clean up their commits into nice, clean, well-titled histories before putting up a PR.
I wouldn't describe it as "cleaning up the history". And the goal isn't to save space, it's to keep a linear history where things ought to be working at each commit (to enable tools like git bisect and similar).
I personally don't ensure everything is working every time I commit - That's what CI is for. The exact process I work through while writing a PR shouldn't impact other people's workflows, so when I merge back into a central branch it should really only reveal the granularity at which I assert 'this code is working and good', which is NOT every intermediate commit I make. Squash merge is a way to do that that fits nicely with existing engineering workflows, like code review.
A truth no one wants to hear. Everyone in denial.
The git blame tip is underrated. People treat it like a gotcha tool but its maybe the fastest way to find the PR/ticket that explains a weird decision.
Thank you.
Diagnostics function, colorized (I tried to add guards so it is portable with terminals that do not support color):
git_diag() {
local since="${1:-1 year ago}"
local root repo branch
# --- patterns ---
local pattern="${GIT_DIAG_PATTERN:-fix|bug|broken|hotfix|incident|issue|patch}"
local firefight_pattern="revert|hotfix|emergency|rollback"
# --- colors ---
local GREP_COLOR_MODE='never'
if [[ -z "${NO_COLOR:-}" ]] && [[ -t 1 ]] && [[ "${TERM:-}" != "dumb" ]] && [[ "$(tput colors 2>/dev/null || echo 0)" -ge 8 ]]; then
local BLACK=$(tput setaf 0)
local RED=$(tput setaf 1)
local GREEN=$(tput setaf 2)
local YELLOW=$(tput setaf 3)
local BLUE=$(tput setaf 4)
local MAGENTA=$(tput setaf 5)
local CYAN=$(tput setaf 6)
local WHITE=$(tput setaf 7)
local BOLD=$(tput bold)
local DIM=$(tput dim 2>/dev/null || true)
local RESET=$(tput sgr0)
GREP_COLOR_MODE='always'
else
local BLACK='' RED='' GREEN='' YELLOW='' BLUE='' MAGENTA='' CYAN='' WHITE=''
local BOLD='' DIM='' RESET=''
fi
local TITLE="$CYAN"
local COLOR_COUNT="$CYAN"
local COLOR_FILE="$YELLOW"
if ! root="$(git rev-parse --show-toplevel 2>/dev/null)"; then
printf 'git_diag: not inside a Git repository\n' >&2
return 1
fi
repo="${root##*/}"
branch="$(git branch --show-current 2>/dev/null)"
branch="${branch:-DETACHED}"
_git_diag_fmt_count() {
local count_color="$1"
local text_color="$2"
awk -v count_color="$count_color" -v text_color="$text_color" -v reset="$RESET" '{
c=$1
$1=""
sub(/^ +/, "")
printf " %s%10d%s %s%s%s\n", count_color, c, reset, text_color, $0, reset
}'
}
printf '%s%sGit repo diagnostics%s\n' "$BOLD" "$TITLE" "$RESET"
printf '%s%-11s%s %s\n' "$BOLD" "Repo:" "$RESET" "$repo"
printf '%s%-11s%s %s\n' "$BOLD" "Branch:" "$RESET" "$branch"
printf '%s%-11s%s %s\n' "$BOLD" "Timeframe:" "$RESET" "$since → now"
printf '\n\n'
printf '%s%s1) Most changed files%s\n' "$BOLD" "$TITLE" "$RESET"
git log --since="$since" --format='' --name-only \
| awk 'NF' \
| sort \
| uniq -c \
| sort -nr \
| head -n 10 \
| _git_diag_fmt_count "$COLOR_COUNT" "$COLOR_FILE"
printf '\n%s%s2) Top contributors%s\n' "$BOLD" "$TITLE" "$RESET"
git shortlog -sn --no-merges --since="$since" \
| head -n 10 \
| awk -v count_color="$COLOR_COUNT" -v reset="$RESET" '{
printf " %s%10d%s %s\n", count_color, $1, reset, substr($0, index($0,$2))
}'
printf '\n%s%s3) Bug/fix hotspots%s %s(pattern: %s)%s\n' "$BOLD" "$TITLE" "$RESET" "$DIM" "$pattern" "$RESET"
git log --since="$since" --format='' --name-only -i -E --grep="$pattern" \
| awk 'NF' \
| sort \
| uniq -c \
| sort -nr \
| head -n 10 \
| _git_diag_fmt_count "$COLOR_COUNT" "$COLOR_FILE"
printf '\n%s%s4) Commit count by month%s\n' "$BOLD" "$TITLE" "$RESET"
git log --since="$since" --format='%ad' --date=format:'%Y-%m' \
| sort \
| uniq -c \
| sort -k2r \
| awk -v count_color="$COLOR_COUNT" -v mag="$MAGENTA" -v reset="$RESET" '
{
data[NR,1] = $2
data[NR,2] = $1
if (length($1) > max) max = length($1)
}
END {
for (i = 1; i <= NR; i++) {
printf " %s%10s%s %s%*d commits%s\n",
mag, data[i,1], reset,
count_color, max, data[i,2], reset
}
}
'
printf '\n%s%s5) Firefighting commits%s %s(pattern: %s)%s\n' "$BOLD" "$TITLE" "$RESET" "$DIM" "$firefight_pattern" "$RESET"
git log --since="$since" -i -E \
--grep="$firefight_pattern" \
--date=short \
--pretty=format:'%ad %h %s' \
| head -n 10 \
| awk -v mag="$MAGENTA" -v dim="$DIM" -v reset="$RESET" '{
date=$1
hash=$2
$1=$2=""
sub(/^ */, "")
printf " %s%-10s%s %s%-12s%s %s\n",
mag, date, reset,
dim, hash, reset,
$0
}' \
| GREP_COLORS='ms=01;31' grep --color="$GREP_COLOR_MODE" -i -E "$firefight_pattern"
}
git_diag() {
local since="${1:-1 year ago}"
local pattern="${GIT_DIAG_PATTERN:-fix|bug|broken|hotfix|incident|issue|patch}"
local root repo branch
if ! root="$(git rev-parse --show-toplevel 2>/dev/null)"; then
printf 'git_diag: not inside a Git repository\n' >&2
return 1
fi
repo="${root##*/}"
branch="$(git branch --show-current 2>/dev/null)"
branch="${branch:-DETACHED}"
_git_diag_fmt_count() {
awk '{
c=$1
$1=""
sub(/^ +/, "")
printf " %10d %s\n", c, $0
}'
}
printf '============================================================\n'
printf 'Git repo diagnostics\n'
printf '%-11s%as\n' 'Repo:' "$repo"
printf '%-11s%s\n' 'Branch:' "$branch"
printf '%-11s%s\n' 'Timeframe:' "$since"
printf '============================================================\n\n'
printf '1) Most changed files (top 10)\n'
git log --since="$since" --format='' --name-only \
| awk 'NF' \
| sort \
| uniq -c \
| sort -nr \
| head -n 10 \
| _git_diag_fmt_count
printf '\n2) Top 10 contributors (no merges, since %s)\n' "$since"
git shortlog -sn --no-merges --since="$since" \
| head -n 10 \
| _git_diag_fmt_count
printf '\n3) Bug/fix hotspots (top 10, matching: %s)\n' "$pattern"
git log --since="$since" --format='' --name-only -i -E --grep="$pattern" \
| awk 'NF' \
| sort \
| uniq -c \
| sort -nr \
| head -n 10 \
| _git_diag_fmt_count
printf '\n4) Commit count by month (since %s)\n' "$since"
git log --since="$since" --format='%ad' --date=format:'%Y-%m' \
| sort \
| uniq -c \
| sort -k2r \
| awk '
{
data[NR,1] = $2
data[NR,2] = $1
if (length($1) > max) max = length($1)
}
END {
for (i = 1; i <= NR; i++) {
printf " %10s %*d commits\n", data[i,1], max, data[i,2]
}
}
'
printf '\n5) 10 most recent firefighting commits (revert|hotfix|emergency|rollback)\n'
git log --since="$since" -i -E \
--grep='revert|hotfix|emergency|rollback' \
--date=short \
--pretty=format:'%ad %h %s' \
| head -n 10 \
| awk '{
date=$1
hash=$2
$1=$2=""
sub(/^ */, "")
printf " %-10s %-12s %s\n", date, hash, $0
}' \
| GREP_COLORS='ms=01;31' grep --color=always -i -E 'revert|hotfix|emergency|rollback'
}*Mainline linux*
Most changed files: pretty much what I expected for 1 and 2... the "cutting edge" 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/gpu/drm/i915/display/intel_display.c) and nvidia is nowhere to be seen (presumably due to out-of-tree modules/blobs?).
186 kernel/bpf/verifier.c
174 fs/namespace.c
162 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
161 kernel/sched/ext.c
159 fs/f2fs/f2fs.h
10399 Christoph Hellwig -> I only know his name because of drama last year regarding rust bindings to DMA subsystem
8481 Mauro Carvalho Chehab -> I also know his name from the classic "Mauro, shut the fuck up!" Linus rant
8413 Takashi Iwai -> Listed as maintainer for sound subsystem, I think he manages ALSA
8072 Al Viro -> His name is all over bunch of filesystem code
1477 drivers/gpu/drm/i915/intel_display.c
1406 MAINTAINERS
1390 sound/pci/hda/patch_realtek.c
1102 drivers/gpu/drm/i915/i915_drv.h
943 arch/x86/kvm/x86.c
928 mm/page_alloc.c
871 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
862 drivers/gpu/drm/i915/i915_reg.h
840 fs/btrfs/inode.c
Most changed files: IR autovectorization code, riscv heuristics tables, and C++ template handling (pt.c is "paramaterized types").
152 gcc/tree-vect-stmts.cc
145 gcc/config/riscv/riscv.cc
131 gcc/tree-vect-loop.cc
116 gcc/cp/pt.cc
1017 gcc/dwarf2out.c
885 gcc/config/i386/i386.c
796 gcc/cp/cp-tree.h
740 gcc/config/rs6000/rs6000.c
720 gcc/cp/pt.c
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.
3298 Olivier Fourdan
530 Anonymous
319 Xfce Bot
121 Jasper Huijsmans
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've yet to see an example of "god help you if you have to change that file" in e.g. linux, but I have of course seen that situation many times in large proprietary codebases.
|sort |uniq -c |sort -nr |head -20
Wtf is happening to this website
Look at the rest of this blog:
Almost no posts since 2020, then a swarm of LLM-style clickbait titles…
Oh wait, the 2020 one also has a clickbait title… and it was substantially rewritten in 2026!!
No need to read them, just a vibe check would be insightful. It's weird how branding, even before AI had a lot of the same catchy patterns, and now it's hard to define what is the right prose (engineers might want one thing and other role families others) and sometimes you're trying to write almost with the "everyone else bag in mind" because that's the personal connections you link your "here's what I often repeat in written form".
TBC, I don't dislike LLM-written articles because I think the author is being lazy, and I can even live with the LLM-isms. I dislike LLM-written articles in the main because they're lousy at serving their purpose of communicating some interesting human thought to other humans. They are very good at creating the illusion that's what's happening, hence all the upvotes.
I also believe that the bulk of that degrade is due to frontier LLM’s currently being poorly trained to write such articles well, given whatever scale & sophistication of prompts the typical author is using.
Not to say they won’t be better someday (soon?)
git rm -rf .