ReadbackLesson 06In progress
2 steps · 30 minutes · one terminal

ORIGIN ISA BOOKMARK

git status tells you your branch is “ahead 1”. It has not spoken to the server — it is reading a file on your own disk that was last updated whenever you last fetched. Here is what your clone actually knows, and what a pull request actually is.

What you already know

Retrieval · lessons 02 and 05

Two from memory before we start. Both matter in about ninety seconds.

Answer before you move on

What is stored in .git/refs/heads/main?

Answer before you move on

Which pair of fields shows that a commit was replayed by a rebase or a cherry-pick?

Status is reading a file

Claim + proof · git status --branch

A clone of a repository. You have made one commit. Someone else — a colleague, or another agent in another worktree — pushed a commit of their own a few minutes ago. You have not fetched.

Ask git where you stand.

Executed, output verbatimBefore fetching
$ git status --short --branch
## main...origin/main [ahead 1]

Unambiguous, confident, and wrong.

Predict before you read on

“Ahead 1” reads as the remote has everything except my one new commit. Given that someone else pushed a few minutes ago, what did git status actually compare your branch against?

Here is the part everyone has backwards

origin/main is not the remote’s branch. It is a local ref holding a cached answer to the question “where was the remote’s main last time I asked?” It is a bookmark, and it goes stale the moment anyone else pushes.

Lesson 02 established that a branch is a file holding one hash. A remote-tracking branch is the same file in a different directory — refs/remotes/origin/main instead of refs/heads/main (Pro Git §10.3). Nothing about it is special, and nothing about it is live.

The proof is the push. If “ahead 1” were true, this would succeed.

Executed, output verbatim
$ git push origin main
To ../origin.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../origin.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

The remote holds work you have never seen. Git will not overwrite it, and says so in the first hint line.

This is the guardrail --force removes

The rejection above is the only thing standing between another person’s commit and oblivion. git push --force removes it unconditionally. git push --force-with-lease removes it only if the remote is still where your last fetch said it was — so it would have refused here, correctly. When an agent force-pushes, this is the difference between a rewrite and a deletion.

What you can check right now

On any repository: git status reports against origin/main, and cat .git/refs/remotes/origin/main shows you the exact hash it is comparing to. If that file is old, so is every “ahead / behind” number you have been reading.

4 of 6 steps remain

Fetch is always safe

You have read the first 2 steps in full — a claim and the verification that settles it. The rest of this lesson, and the 9 lessons after it, open when subscriptions do. Nothing that is free today will be taken away then.

Read the free reference
Subscriptions open soon
the free preview stays