Two dots, three dots

I lost time to one missing dot.

A Cmdline branch failed a SlashGo SQLx check. I had not touched SlashGo. The usual explanation was “monorepo stuff,” which is not an explanation, so I looked at how the pre-push hook selected changed files.

It used:

git diff --name-only origin/main..HEAD

I wanted the files changed by the branch. That command compares the two current trees.

Those are only the same thing when the branch is caught up with main.

If main has moved since the branch split, the two-dot diff includes both the branch’s work and everything main gained afterward. The hook then confidently runs checks for code the branch never contained.

On the branch that exposed it:

origin/main..HEAD      29 files, including 8 SlashGo files
origin/main...HEAD      4 files, all Cmdline

Three dots compare HEAD with the merge base:

git diff --name-only origin/main...HEAD

That asks the question I actually meant: what changed on this branch?

We had the two-dot form in five gates—Rust, migrations, TypeScript, packages, and lockfiles—so one character was making the whole pre-push suite depend on how recently someone rebased.

Rebasing appeared to fix it. It did not. It just made the endpoint trees line up for a while. Main could move again before the next push, which happens constantly when several agents and people are working at once.

The fix was adding a dot in five places.

Git syntax has the unfortunate property of looking decorative while describing a graph operation. Two dots and three dots are not stylistic variants.

If a hook is trying to inspect work introduced by a branch, it probably wants the merge base.

Anyway, twenty-nine files became four. SlashGo stopped complaining about work it had never seen. One dot.