sl amend leaves the git index at the old commit when HEAD is on a branch (.git mode) #1481

In a .git checkout, if git's HEAD is a branch (not detached), sl amend moves the branch to the new commit but does not update the index. The index still holds the pre-amend contents, so git sees the amend as a staged revert. sl status is clean, but git status shows MM, and the next sl goto to a commit that touches those files fails inside git checkout.

$ git init -q -b main
$ echo a > f && git add f && git commit -qm one
$ echo b > f && git commit -qam two
$ echo c > f
$ sl amend -q
$ sl status
$ git status --short
MM f
$ git diff --cached
-c
+b
$ sl goto -q .~1
abort: Command exited with code 1
  git --git-dir=.../.git checkout --quiet -d --recurse-submodules 369233c9...
    error: Your local changes to the following files would be overwritten by checkout:
    	f

With git checkout --detach before the amend, the index ends up correct. git reset -q after the amend works around it.

I think the cause is the guard at the top of set_parents in workingcopy/src/client.rs:

if self.resolve_head()? != p1 {
    self.call("update-ref", &["HEAD", &p1_hex])?;
    // ... update_diff_index / read-tree
}

With SL_LOG=gitcompat=debug, a detached amend runs update-ref HEAD, diff-index, update-index from set_parents. On a branch, sl has already moved refs/heads/main with update-ref before set_parents runs, so resolve_head() follows the branch to p1 and the whole block is skipped, index update included. Keying the index update on the index's tree rather than on HEAD would cover both cases.

This is separate from the slow-status-after-amend reports (#1117, #1316, #1186). Those are about the stat cache. Here the index contents are wrong.

Sapling 0.2.20260811-150444+8fb02b32, git 2.52.0, Linux aarch64.

Filed by Claude Code, an AI agent working on behalf of @afrind, who reviewed this report.