Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to write-up pairs each git success message with the state it actually leaves behind, and on git 2.39.5 the gap shows up in the index, then again in a fixup! commit that survived a rebase, and once more in a pull request GitHub called mergeable.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
The stability step is a branch, not a pipeline: inside one team's release-candidate discipline1 distinct publisher
build
A success message keyed on reaching a line reported 39 days of pushes that never left the box1 distinct publisher
build
Stop trying to remember your Git email: includeIf makes identity a property of the directory1 distinct publisher
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
rerere replays a conflict resolution it remembers, and when it fires the rebase prints `Staged 'f.txt' using previous resolution` [2]. The recording step is where the mental model usually breaks. The postimage gets written when you commit, when you run `git rebase --continue`, or when you invoke `git rerere` directly, and `git add` is not one of those [3]. `git rebase --abort` separately runs `rerere clear`, which wipes the in-flight metadata [4]. The author is straight about the limit of his own test: he could not separate the two mechanisms, so he reports both [5]. What he could measure on git 2.39.5 is that an explicit `git rerere` before the abort is enough to make the resolution replay, before the rebase goes anywhere [6]. That result is scoped to one version.
Autoupdate is worth arguing about because of what rerere will cheerfully do. A resolution taught in `one.txt` replayed into `two.txt`, a different file on a different branch, because the conflicting hunk matched, and where the correct answer differs between the two places you silently get the first one [7]. With autoupdate off, rerere still writes its answer into the working tree; the index just leaves the path as `UU`, so you have to read it and add it yourself [8][9]. Turn autoupdate on and the same path reads `M`, fully staged, with nothing prompting a look [8]. The recovery pair is `git rerere forget <path>` to drop what it learned and `git checkout -m <path>` to bring the markers back [10], which only helps if you noticed.
The autosquash flow has two edges. `git commit --fixup abc1234` marks the commit and `git rebase -i --autosquash abc1234~1` opens a todo list already ordered correctly [11]; a bare `git rebase -i --autosquash` with no range fails outright on a branch with no upstream [12]. A range that does not reach back far enough to include the target does not warn at all, and prints `Successfully rebased and updated` with the `fixup!` commit still sitting there [13]. The message is technically accurate, and that accuracy is the trap: it says nothing about a leftover fixup! commit, so running `git log --oneline | grep fixup!` afterwards is the step that actually carries information [14]. Note the asymmetry in blast radius: `git commit --fixup` only adds a commit, while the rebase rewrites history, so the rule about shared commits applies to the second line [15].
The stacked-PR case supplies arithmetic. Compare put head `b1cf109` against `main` at `e6dc136` as diverged, behind by 8, and after `git merge origin/main` produced `b4ac271` the same branch was behind by 0 [17]. Subtract the two: the merge carried all 8 commits, and the retarget carried none of them [1]. That matches what the buttons do, since Change base only alters what the PR is compared against, while Update branch or a plain merge moves commits [19]. Locally, `git merge-base --is-ancestor origin/main HEAD` answers it, exit 1 being the stale case [18].
The bill landed on the review loop. The automated reviewer worked from that stale head, raised a finding about an implementation already replaced on main, and the author burned a cycle on code that existed only on the branch [21]. He notes the SHAs come from a private stack, so this one is a field note rather than something you can clone, though the two-line ancestry check ports anywhere [20]. Every check that held up here interrogates state directly instead of trusting the message the command printed.
Ranked by verification strength, evidence, and original report placement.
The author's method is to set up the case, run the command, then check the state he actually cared about instead of trusting the success message.
rerere stands for reuse recorded resolution: it remembers how a conflict was resolved and replays it when the same conflict appears, printing "Staged 'f.txt' using previous resolution."
git add does not record the rerere postimage; git commit, git rebase --continue, or an explicit git rerere do.
git rebase --abort runs rerere clear, which wipes the in-flight rerere metadata.
The author states his test could not separate the two mechanisms (postimage recording and rerere clear on abort), so he reports both.
Measured on git 2.39.5: resolve plus git add plus abort recorded nothing and the next attempt conflicted identically, while resolve plus git add plus an explicit git rerere plus abort replayed the resolution before the rebase went anywhere.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-hand, version-pinned, mostly re-runnable
Most of this is a command you can paste and a state you can read back: UU versus M in the index, the git version written down as 2.39.5, the exact string autosquash prints while leaving a fixup! commit behind. What is absent is a second pair of hands — no git documentation, no upstream thread, no other publisher — and two items sit softer than the rest: the claim about how guides pair the two rerere settings names no guide, and the pull-request measurement comes from a repo nobody else can open.
No usage signal exists to read
Nothing in this reporting tells us how many developers actually leave rerere.autoupdate off, whether any team added the ancestry check to a gate, or how widely the pull-request trap bites. Answering that would need config surveys, repo scans or platform data, and none of it is here — a single author's bench notes cannot stand in for it.
Claims stay inside what the terminal showed
The loudest thing on the page — a replayed resolution staged before anyone checks which file it landed in — is exactly what the author put in front of the index and reported. He then gives away the two places his evidence thins: his test cannot separate the lost postimage from rerere clear, and the eight-commits-behind story is unshareable. A post that hedges its own findings is slightly under-claiming what it demonstrated, not over-claiming it.
Self-published, nothing being sold
The piece grew out of a comment on Sylwia Laskowska's git list and it sells nothing: no vendor, no tool of the author's, no course at the end, and the recommendation actually costs the reader convenience by telling them to switch a setting off. What pressure remains is the ordinary dev.to kind — a list of sharp edges travels further than a careful paragraph, and no editor sat between the measurement and the publish button.
Checkable by anyone, corroborated by no one
One author, one machine, one git version is thin — but thin in the cheap-to-fix way: the resolve, add, abort sequence takes five minutes in a scratch repo, and the fixup! survival is a grep away. We hold at mid-range because the git items would very likely survive that test while the GitHub item cannot be subjected to it at all, and because the one claim about how the wider ecosystem documents rerere has no support behind it.