Scenario: local-edit-in-the-squash
The parent scenario's squash merge, but the feature
branch also edited the folder. So one commit, s, does two things: it
records the pulled upstream commit f in .splice, and it holds a local
edit that the upstream doesn't have, local.txt.
Output
setup.bash builds this state:
$ build_scenario scenario_local_edit_in_the_squash
The sync model's table draws
the same commits for this case, with the upstream's main at f:
s is the last commit, and the only one since the clone a:
$ git log --format=%s
feature (squash-merged)
add vendor/a
initial commit
What the squash merge records, and what it holds
s's .splice records f, U(H):
$ git -C "$UPSTREAM" log -1 --format=%s "$(git config --file vendor/a/.splice splice.commit)"
upstream feature work
But its folder isn't f: it has the local edit too.
$ synced="$(git config --file vendor/a/.splice splice.commit)" &&
> git diff --name-only "$synced" HEAD:vendor/a -- ':!.splice'
local.txt
Where the rebuild starts
So s can't be B, the newest commit that changed
.splice and whose folder is the commit it recorded
(sync model). The rebuild
copies s, and starts where it would have before s, at the clone, a:
$ git log -1 --format=%s "$(git splice boundary vendor/a)"
add vendor/a
The rebuild copies the commits after B:
$ git log --format=%s "$(git splice boundary vendor/a)..HEAD" -- vendor/a
feature (squash-merged)
R is that copy, s', on top of f:
$ git log --format=%s "$(git splice rebuild vendor/a)"
feature (squash-merged)
upstream feature work
seed
Before, B was s itself, because its .splice changed.
Then git log B..HEAD was empty, while a push still sent the local edit.
Push
The upstream's main gets both: f, and s' with the local edit, under
s's message.
$ git splice push vendor/a
ok vendor/a: pushed 0461d52 to main
$ git -C "$UPSTREAM" log --format=%s main
feature (squash-merged)
upstream feature work
seed