Scenario: Sapling's Git index and branch state
Sapling works in a Git working copy, but git-splice observes Git's
index and branch state. In the pinned Sapling version, sl amend leaves
stale staged contents, and sl prev detaches Git's HEAD.
Output
setup.bash builds a monorepo with vendor/lib/ as a splice:
$ build_scenario scenario_sapling_git_index
$ sl --version 2>/dev/null | head -1
Sapling 0.2.20260929-102736+288e0c2d
A Sapling commit keeps Git on its branch:
$ echo "fix" >>vendor/lib/src/parse.txt &&
> sl commit -q -m "fix parse" &&
> git status | head -n 1
On branch main
After an amend, Git reports staged and unstaged changes:
$ echo "more" >>vendor/lib/src/parse.txt &&
> sl amend -q &&
> git status --short
MM vendor/lib/src/parse.txt
The push sends the amended commit, but warns about the stale index state:
$ git splice push vendor/lib
?? vendor/lib: uncommitted changes aren't pushed -- commit them first
ok vendor/lib: pushed df5904d to main
With no intentional staged changes in this example, reset the index:
$ git reset -q && git status --short
Moving with Sapling detaches Git's HEAD, so syncing refuses:
$ sl prev -q && git splice status
[5646f5] add vendor/lib
!! not on a branch (detached HEAD) -- git splice requires a named branch
[1]
Select the Git branch again:
$ git checkout -q main && git splice status
On branch main
up to date vendor/lib