{"id":691,"date":"2026-09-16T13:01:25","date_gmt":"2026-09-16T13:01:25","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/laravel-pint-the-one-commit-that-broke-my-git-blame\/"},"modified":"2026-09-16T13:01:25","modified_gmt":"2026-09-16T13:01:25","slug":"laravel-pint-the-one-commit-that-broke-my-git-blame","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/laravel-pint-the-one-commit-that-broke-my-git-blame\/","title":{"rendered":"Laravel Pint: The One Commit That Broke My Git Blame"},"content":{"rendered":"

Short version for the impatient: run Laravel Pint once, in its own commit, add that commit hash to a .git-blame-ignore-revs<\/code> file, and put pint --test<\/code> in CI instead of the auto-commit bot the docs suggest. If you want to know why I’m so specific about this, it’s because I did it the other way first and spent a Thursday afternoon explaining to a client why every line in their codebase now said I wrote it.<\/p>\n

The app was a four-year-old Laravel project I’d inherited. Three previous developers, three coding styles, a .php_cs<\/code> file from 2021 that nobody had run since, and a README that described a different app. I added Pint, ran it, and it rewrote 640 files. That part was fine. What wasn’t fine was that I committed it alongside a bug fix, and from that moment git blame<\/code> on any file pointed at me. The one tool you reach for when you need to ask “who wrote this and why” was gone.<\/p>\n

So this post is about the boring parts of adopting Pint on a real project. The formatter itself takes thirty seconds to learn. The stuff around it took me a week to get right.<\/p>\n

What Pint is and isn’t<\/h2>\n

Laravel Pint<\/a> is a wrapper around PHP CS Fixer<\/a> with an opinionated default rule set. It ships with new Laravel apps, so you probably already have it in vendor\/bin<\/code>. If you don’t, it’s one Composer line:<\/p>\n

composer require laravel\/pint --dev\n.\/vendor\/bin\/pint\n<\/code><\/pre>\n
With no config at all it applies the laravel<\/code> preset. There are four others (per<\/code>, psr12<\/code>, symfony<\/code>, and empty<\/code>), and you can override individual PHP CS Fixer rules in a pint.json<\/code> file at the project root. That is the entire configuration surface. I’ve never needed more than this:<\/p>\n
{\n    "preset": "laravel",\n    "rules": {\n        "simplified_null_return": true,\n        "concat_space": {\n            "spacing": "one"\n        }\n    },\n    "exclude": [\n        "storage",\n        "bootstrap\/cache"\n    ]\n}\n<\/code><\/pre>\n
What Pint isn’t: a linter. It won’t tell you a variable is unused or a method returns the wrong type. It only cares about whitespace, braces, imports, and the handful of syntax rewrites PHP CS Fixer knows how to do safely. If you want the bug-catching half of the story, that’s PHPStan or a language server, and I wrote about the route typo PHPStan can’t see<\/a> if you’re weighing those up. Pint and static analysis are different tools and I’d run both.<\/p>\n
Here’s the kind of thing Pint changes, using a method I pulled from that inherited codebase (names changed):<\/p>\n
<?php\nnamespace App\\Services;\nuse App\\Models\\Order;\nuse Illuminate\\Support\\Collection;\n\nclass OrderTotals {\n    public function __construct( private Collection $orders ){}\n\n    public function unpaid() : Collection\n    {\n        return $this->orders->filter(function($o){\n            return $o->status=="unpaid";\n        })->values();\n    }\n}\n<\/code><\/pre>\n
After one run with the laravel<\/code> preset:<\/p>\n
<?php\n\nnamespace App\\Services;\n\nuse App\\Models\\Order;\nuse Illuminate\\Support\\Collection;\n\nclass OrderTotals\n{\n    public function __construct(private Collection $orders) {}\n\n    public function unpaid(): Collection\n    {\n        return $this->orders->filter(function ($o) {\n            return $o->status == 'unpaid';\n        })->values();\n    }\n}\n<\/code><\/pre>\n
Blank line after the opening tag, brace on its own line for the class, spaces around the closure parameters, single quotes. None of it changes behaviour. All of it changes the diff. Multiply that by 640 files and you see the blame problem coming.<\/p>\n
The one-commit rule<\/h2>\n
When you adopt a formatter on an existing project, the first run is going to touch most of the repository. The mistake I made was treating that as a normal change. It isn’t. It’s a change with zero semantic content that happens to rewrite a huge number of lines, and it deserves to be isolated.<\/p>\n
My rule now is that the formatting run gets its own commit, with nothing else in it, and a message that says exactly what it is:<\/p>\n
git checkout -b chore\/adopt-pint\n.\/vendor\/bin\/pint\ngit add -A\ngit commit -m "chore: apply Laravel Pint to the whole codebase (no functional changes)"\n<\/code><\/pre>\n
Then, and this is the part I didn’t know existed, you tell Git to skip that commit when computing blame. Git has supported an --ignore-revs-file<\/code> option on git blame<\/code> since 2.23, and the git-blame docs<\/a> describe the blame.ignoreRevsFile<\/code> config that makes it automatic. The convention is a file called .git-blame-ignore-revs<\/code> at the repo root:<\/p>\n
# Laravel Pint adoption, whole-repo formatting, no functional changes\na91c4e7d0b2f6e1c3d5a8b9f0e2d4c6a8b0f1e3d\n<\/code><\/pre>\n
Commit that file, then set the config once per clone:<\/p>\n
git config blame.ignoreRevsFile .git-blame-ignore-revs\n<\/code><\/pre>\n
GitHub’s blame view<\/a> reads the same file automatically, so the web UI skips the formatting commit too. VS Code’s GitLens respects the config setting. After this, blame on any line points at whoever wrote the line before Pint reindented it, which is what you wanted all along.<\/p>\n
I’d already merged my version by the time I learned about this, so I had to do the annoying thing and revert the merge, split the commit in two, and redo it. Twenty minutes of work that would have been two if I’d known. Now you know.<\/p>\n
CI: why I don’t use the auto-commit action<\/h2>\n
The Laravel docs give you a GitHub Actions workflow that runs Pint on every push and then uses stefanzweifel\/git-auto-commit-action<\/code> to commit whatever it changed back to your branch. I tried it for about a week and turned it off.<\/p>\n
The problem is that a bot is pushing commits to the branch you’re working on. You push, the bot pushes a fix-up, you try to push again and get rejected because your local branch is behind. On a solo project it’s a mild annoyance. With two people on the same feature branch it’s a small daily fight. And it hides the underlying issue, which is that somebody’s editor isn’t formatting on save.<\/p>\n
What I run instead is a check, not a fix:<\/p>\n
name: Code style\n\non: [pull_request]\n\njobs:\n  pint:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v5\n        with:\n          fetch-depth: 0\n\n      - uses: shivammathur\/setup-php@v2\n        with:\n          php-version: "8.4"\n          tools: pint\n\n      - name: Pint (test mode, changed files only)\n        run: pint --test --diff=origin\/main\n<\/code><\/pre>\n
Two flags doing the work. --test<\/code> makes Pint exit non-zero if anything would change, without changing it. --diff=origin\/main<\/code> restricts the check to files that differ from main<\/code>, so a 900-file project doesn’t get fully re-scanned on every pull request. The fetch-depth: 0<\/code> is required because --diff<\/code> needs the branch history to compare against, and I lost twenty minutes to a red build before I worked that out. If you keep a lot of workflows like this one, I’ve written about reusable GitHub Actions workflows and the bug I kept reintroducing<\/a>, which is where this job now lives for me.<\/p>\n
There’s a middle option, --repair<\/code>, which fixes the files and still exits non-zero. I use it locally, never in CI, because a CI job that mutates files it then throws away is just a slower --test<\/code>.<\/p>\n
The pre-commit hook that makes CI boring<\/h2>\n
If CI only ever fails on style, you’ve moved the problem somewhere slower and more public. The fix is to catch it before the commit exists. Pint has a --dirty<\/code> flag that limits it to files with uncommitted changes according to Git, which is exactly what a pre-commit hook wants:<\/p>\n
#!\/bin\/sh\n# .git\/hooks\/pre-commit (or wire it through your hook manager of choice)\n.\/vendor\/bin\/pint --dirty --repair\nif [ $? -ne 0 ]; then\n    echo "Pint reformatted staged files. Review and re-stage them."\n    exit 1\nfi\n<\/code><\/pre>\n
The --repair<\/code> there is deliberate. It fixes the files and then fails the commit, so you look at what changed before it goes in. I tried the version that silently re-stages the fixed files and I didn’t like it; a commit that contains lines I never saw is a commit I can’t vouch for.<\/p>\n
On the 640-file project, --dirty<\/code> runs in well under a second because it’s only looking at whatever I touched. Full runs on the same codebase take a few seconds, or less with --parallel<\/code>, which the docs mark as experimental and which I’ve had no trouble with on a laptop. You can cap it with --max-processes=4<\/code> if it’s eating a CI runner alive.<\/p>\n
Two rules I’d think twice about<\/h2>\n
Pint ships a couple of custom rules under the Pint\/<\/code> prefix that are off by default. I turned both on, then turned one off.<\/p>\n
Pint\/laravel_blade<\/code> formats your .blade.php<\/code> files. Under the hood it shells out to Prettier with the Blade and Tailwind plugins, which means Node has to be installed wherever Pint runs, including your CI runner. That’s an extra setup step the PHP-only workflow above doesn’t have. I kept the rule on because the Blade templates on that project were the ugliest part of it, but I had to add a Node setup step to the workflow, and I want you to know that before you enable it and wonder why CI broke.<\/p>\n
Pint\/phpdoc_type_annotations_only<\/code> is the one I backed out of. It strips every comment that doesn’t contain an @<\/code> annotation. The docs are honest about this: single-line and block comments without annotations are removed entirely, and you keep a comment only by prefixing it with one of the three annotation tags the docs list (@note<\/code> is the one I ended up using). On a fresh project where you control every comment, fine. On an inherited codebase, I watched it delete a comment that said why a retry loop had a 3-second sleep in it, and that comment was the only documentation the retry had. I restored the file and removed the rule. If you want it, run it once on a branch and read the diff before you commit. The config<\/code> directory is skipped automatically, which tells you the maintainers hit the same problem.<\/p>\n
What I’d do this week<\/h2>\n
If you have a Laravel project that doesn’t run Pint yet, here’s the order I’d do it in, and it fits in an afternoon.<\/p>\n
Create a branch. Run .\/vendor\/bin\/pint<\/code> with no config and commit the result on its own. Add the hash to .git-blame-ignore-revs<\/code>, commit that, and run git config blame.ignoreRevsFile .git-blame-ignore-revs<\/code>. Open a file you know was written by someone else and check that blame still says so. Then add the --test --diff=origin\/main<\/code> job to CI and the --dirty --repair<\/code> pre-commit hook, and merge.<\/p>\n
Leave pint.json<\/code> alone until the default preset annoys you about something specific. Mine has two rule overrides after a year, and I’m not sure the second one was worth the argument.<\/p>\n
I’ve been doing this on every Laravel codebase I take over, and it’s become the first commit in every engagement listed on my portfolio<\/a>. Formatting isn’t exciting. It is the cheapest way I know to make a stranger’s code feel like mine before I start changing it.<\/p>\n","protected":false},"excerpt":{"rendered":"
I adopted Laravel Pint on a 640-file legacy app and wrecked git blame. Here’s the one-commit fix, .git-blame-ignore-revs, and the CI check I run instead of the bot.<\/p>\n","protected":false},"author":2,"featured_media":690,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"I adopted Laravel Pint on a 640-file legacy app and wrecked git blame. Here's the one-commit fix, .git-blame-ignore-revs, and the CI check I run instead of the bot.","rank_math_focus_keyword":"laravel pint","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[173,52],"tags":[769,770,708,56,53,768],"class_list":["post-691","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-laravel","category-php","tag-code-style","tag-git","tag-github-actions","tag-laravel","tag-php","tag-pint"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/691","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=691"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/691\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/690"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=691"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=691"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=691"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}