Scenario: squash-merged-pull

A pull on a feature branch, squash-merged into main.

Upstream: seed on main, and someone else's commit on feature.
Monorepo (vendor/a/): cloned at seed. On feature, git splice pull brought in the upstream commit. feature was squash-merged into main and deleted, then a local commit followed on main.

A squash merge keeps the content and drops the history. With git subtree, that lost the sync point. Here the squash merge itself changed .splice, so it is the new boundary, and the rebuild starts at the pulled upstream commit: a push sends only the local commit.

The monorepo's a, the squash merge s and c; the upstream's k on main and f on feature; R is c prime on top of f, and B is s

The drawing names the monorepo's commits a (add vendor/a), s (the squash merge) and c (local change), and the upstream's k (seed, T) and f (upstream feature work).

Output

setup.bash builds this state:

$ build_scenario scenario_squash_merged_pull

The drawing shows what Git and git-splice say about it, with each commit named by its place in the history (check_drawing):

$ check_drawing "$TESTDIR/squash-merged-pull.drawio.svg" a=HEAD~2 s=HEAD~1 c=HEAD k=refs/splices/upstream/main f=refs/splices/upstream/feature
ok   squash-merged-pull.drawio.svg: 6 commits, 9 arrows, 5 boxes, 0 frames

$ git log --format=%s
local change
feature (squash-merged)
add vendor/a
initial commit

$ git splice status
On branch main

  ahead 2  vendor/a

$ git splice log
===  vendor/a (main)
< 5c5de89 local change  (Test <test@example.com>)
< 223f9b4 upstream feature work  (Test <test@example.com>)

$ git splice push vendor/a
ok   vendor/a: pushed 5c5de89 to main

$ git -C "$UPSTREAM" log --format=%s main
local change
upstream feature work
seed

Output​

Output