Scenario: after-a-push

The parent scenario's recipe takes the upstream commits of a pull X from .splice: U(X^) in X's first parent, U(X) in X. That's only right if X merged from U(X^). After a push, it didn't. Here, the parent's pull is c, a local change, e, was pushed as e', and X pulled o.

U(e)..U(X) is e' and o, though X only brought in o.

Output

setup.bash builds this state:

$ build_scenario scenario_after_a_push

$ git log --format=%s
splice: pull vendor/a from main at 747a38b
e: a local change in vendor/a
d: add notes
splice: pull vendor/a from main at b413207
b: add check.sh
a: add vendor/a
initial commit

X is the newest pull. The recipe's range has the pushed commit too:

$ X=HEAD &&
>   U1="$(git config --blob "$X^:vendor/a/.splice" splice.commit)" &&
>   U2="$(git config --blob "$X:vendor/a/.splice" splice.commit)" &&
>   git log --format=%s "$U1..$U2"
o: add upstream.txt
e: a local change in vendor/a

A push doesn't write to the monorepo, so .splice in X's first parent still names the commit of the first pull (pushed-then-pulled). X merged from the pushed commit, and only brought in add upstream.txt. The pushed commit's change was in the monorepo before X:

$ git show "$X^:vendor/a/file.txt"
seed, fixed
a local line

So the second bisect tests a commit the monorepo already had. Bisect assumes one change from good to bad in the range. If the pushed commit broke the test and a later one fixed it, bisect can name the pushed commit, though X didn't bring it in.

A splice made with git splice init and pushed has no synced commit at all, so U(X^) is empty and the recipe stops at its first command.

In both cases, the lower bound is where X's merge started: where the monorepo's history, rebuilt as upstream commits, meets the upstream's. Only git-splice computes that, so plain Git can't get it from .splice. #109 proposes git splice show <commit>, which could print the range from there.