This morning git pull --rebase printed a success line and deleted the
commit you pushed yesterday. No conflict, no error, no prompt. The
working tree is clean, the branch says up to date, and the commit is on
no branch anywhere: not yours, not the remote's.
Nothing in that story fails, which is what makes it dangerous.
Reproducing it takes two clones and four commits. Watch it happen, get
the commit back, then meet the rule that decided your pushed work was
disposable. Git 2.51, stock configuration, throughout.
Two clones, one branch
Your teammate started the branch search and pushed two commits; you
cloned and joined. Your contribution is a ranking fix:
$ git log --oneline
97d747a Index file paths
5d48fd5 Add search command
$ git add ranking.js
$ git commit -m "Rank exact matches first"
[search 5a818d0] Rank exact matches first
1 file changed, 1 insertion(+)
create mode 100644 ranking.js
$ git push
To …/origin.git
97d747a..5a818d0 search -> search
5a818d0 is on the remote now; anyone who fetches gets it. The push
also did one other thing, quietly, in your own clone. It comes back
when we get to the why.
The force push you never saw
Your teammate's clone hasn't fetched since before your push, so their
branch still ends at 97d747a, and they've just committed a filter:
$ git add filters.js
$ git commit -m "Match on file type"
[search d5c109a] Match on file type
1 file changed, 1 insertion(+)
create mode 100644 filters.js
$ git push
To …/origin.git
! [rejected] search -> search (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 work the remote contains that they do not have is your commit. The
refusal is Git protecting it, and the hint says how to take it in. They
read the refusal as friction:
$ git push --force
To …/origin.git
+ 5a818d0...d5c109a search -> search (forced update)
The last post was about
this moment from the pusher's side, and about the flags that would have
refused it. Today the interest is on your side of the wire, because
nothing so far has touched your clone. The remote lost its copy of
5a818d0; yours is intact, checked out, one git log away. The deletion
that sticks is going to be yours.
The pull
$ git pull --rebase
From …/origin
+ 5a818d0...d5c109a search -> origin/search (forced update)
Successfully rebased and updated refs/heads/search.
$ git log --oneline
d5c109a Match on file type
97d747a Index file paths
5d48fd5 Add search command
$ git status
On branch search
Your branch is up to date with 'origin/search'.
nothing to commit, working tree clean
Your commit is gone, and every signal reads as routine. The fetch did
disclose what it saw: one (forced update) line, the same dialect the
last post decoded. The rebase then proceeded as if that line settled
things. "Up to date" here means agreeing with a remote that was
force-pushed a minute ago.
The rescue
Reason later; rescue the commit first. The branch's reflog (the local diary of
the positions search has held in your clone) still lists it:
$ git reflog search
d5c109a search@{0}: pull --rebase (finish): refs/heads/search onto d5c109ab3f4881e4f58b8de14947c0cb23a202ee
5a818d0 search@{1}: commit: Rank exact matches first
97d747a search@{2}: clone: from …/origin.git
search@{1} is the branch as it stood before the pull rewrote it. If
your tree isn't clean, git stash --include-untracked first —
--hard throws away uncommitted changes. Then move back:
$ git reset --hard search@{1}
HEAD is now at 5a818d0 Rank exact matches first
$ git log --oneline
5a818d0 Rank exact matches first
97d747a Index file paths
5d48fd5 Add search command
$ git status -sb
## search...origin/search [ahead 1, behind 1]
If you'd already committed new work on top of the pulled branch
before noticing, reset would take it down with the pull's result; in
that case git cherry-pick 5a818d0 brings the lost commit onto the
current state instead. A branch repaired that way already sits on
top of origin/search, so there is nothing left to integrate: skip
the reset below, git push, and git stash pop if you stashed
at the start.
Ahead 1, behind 1 is the divergence the pull was supposed to resolve,
now out in the open: you have a commit missing from the remote, the
remote has one you haven't integrated. If you took the reset path, that
gets resolved in Integrating it properly, below. First, the reason.
Why the rebase threw it away
A rebase pull is a fetch, then a rebase of your branch onto the updated
origin/search. The rebase's first job is drawing a boundary: which
commits are yours to replay onto the new tip, and which belonged to the
old upstream, where replaying would only resurrect discarded history.
Git has two ways to draw that boundary, and they disagree about you:
$ git merge-base origin/search search
97d747a8a37a3b4cf5d3032ff2504761c898646e
$ git merge-base --fork-point origin/search search
5a818d0272d94df7a2b447d349402105f8df8c0a
Plain merge-base answers from the commit graph: the two histories
part ways after 97d747a, so everything past it on your branch is yours
to replay — one commit, 5a818d0. That is the boundary an explicit
git rebase origin/search would use.
--fork-point is what git pull uses, and it consults something the
graph doesn't have: the reflog of your remote-tracking ref.
origin/search is your clone's private record of the remote branch,
and it keeps a diary of its own:
$ git reflog origin/search
d5c109a refs/remotes/origin/search@{0}: pull --rebase: forced-update
5a818d0 refs/remotes/origin/search@{1}: update by push
update by push. Your push didn't just send the commit; it recorded,
in your own clone, that the upstream branch has stood at 5a818d0. The
fork-point rule treats every position in that diary as upstream
history — and the upstream has since moved off 5a818d0, so by its
reading, the upstream considered your commit and threw it away. The
boundary lands on the commit itself, the replay set is empty, and the
rebase does exactly what it was asked, for the branch it believed it
was looking at.
The rule exists for a real case. If a maintainer rewrites a branch
under commits you have not pushed, fork-point is what stops the
rebase from replaying the abandoned upstream commits underneath your
work: no duplicates, no phantom conflicts from history the rewrite
meant to delete. It guards unpushed work sitting on rewritten history.
The trap is that the diary records positions, never ownership. A commit
you pushed and a commit the upstream abandoned are indistinguishable in
it, and your own push is what put yours on the list. That is the quiet
other thing the push did back in the first block.
The flag that doesn't exist
git rebase can be told not to do this: --no-fork-point, or
rebase.forkPoint=false in config. Neither survives contact with
git pull. The flag first:
$ git pull --rebase --no-fork-point 2>&1 | head -2
error: unknown option `no-fork-point'
usage: git pull [<options>] [<repository> [<refspec>...]]
The config setting looks like it should reach the rebase that pull
runs underneath. Watch it not do that: this next run has
rebase.forkPoint=false set, and GIT_TRACE prints what pull executes:
$ GIT_TRACE=1 git -c rebase.forkPoint=false pull --rebase 2>&1 | grep -oE "run_command: git (merge-base|rebase).*"
run_command: git merge-base --fork-point refs/remotes/origin/search search
run_command: git rebase --no-autostash --onto d5c109ab3f4881e4f58b8de14947c0cb23a202ee 5a818d0272d94df7a2b447d349402105f8df8c0a
$ git log --oneline
d5c109a Match on file type
97d747a Index file paths
5d48fd5 Add search command
Gone again, config and all. The trace is the explanation. Pull computes
the fork point itself (the first line) and hands the verdict to rebase
as an explicit --onto: rebase onto d5c109a, replaying whatever
follows 5a818d0. By the time rebase would consult rebase.forkPoint,
the decision is already spelled out in its arguments, and a setting
can't override an argument. As of Git 2.51 there is no pull-side flag
and no config that reaches this: every rebase pull across a rewritten
upstream gets the fork-point verdict whenever the reflog can supply
one — and your own push made sure it can.
Integrating it properly
So the fix has to happen outside the pull. First, back to the rescued
commit — by hash this time: if you skipped the traced demonstration,
your reflog positions differ from mine, and the hash is correct on
either path. Then rebase onto the explicit name — naming the upstream
is what makes rebase use the plain merge-base boundary:
$ git reset --hard 5a818d0
HEAD is now at 5a818d0 Rank exact matches first
$ git rebase origin/search
Successfully rebased and updated refs/heads/search.
$ git log --oneline
aeae0fd Rank exact matches first
d5c109a Match on file type
97d747a Index file paths
5d48fd5 Add search command
$ git push
To …/origin.git
d5c109a..aeae0fd search -> search
Your change is back on the branch: aeae0fd, a new hash because the
parent changed, same message and content, sitting on top of your
teammate's work, published with an ordinary fast-forward push. Both
commits survive. This is what the pull would have done had it drawn the
boundary from the graph instead of the diary. If you stashed at the
start, git stash pop brings that work back; the incident is over.
(A bare git rebase with no upstream argument defaults to the same
fork-point rule as pull, so name the upstream when it matters.)
A (forced update) line in any fetch or pull output is the only
warning you get. When you see it, stop pulling by reflex. Read what moved
(git log --oneline origin/search), check whether your own pushed
commits are still part of it, and integrate with an explicit
git rebase origin/<branch> so the boundary comes from the graph.
Or don't do any of this
The check you just ran by hand is two read-only commands: fork point
against merge base, with the at-risk commits sitting between them. A
Git client can afford to run that check before every rebase pull.
GitDesktop runs it as a pre-flight check. When the two
answers agree, the pull proceeds as normal. When they disagree, it
stops before the rebase and asks "Keep or drop these commits?", with
each at-risk commit listed by id, subject, and date. Keeping them
replays them on top of the rewritten upstream, the same move as the
explicit rebase above, and it's the focused default. Dropping them is
allowed too (sometimes the rewrite really did mean to take your commit
with it), and a drop is recorded in Operation history rather than
trusted to memory. The transcript above, with its one success line,
becomes a question with the evidence attached.
A success message tells you the plan worked. It never tells you the
plan was right.
