Sapling
Sapling (sl) can work in a Git repository,
and git-splice runs next to it there
(comparison). Its sl subtree
also records sync points, in the commit instead of a file. This page says
what git-splice could do about both. None of it is planned yet.
Next to sl
- The current branch.
sl commitkeeps Git on its branch, butsl gotoleavesHEADdetached, andsl goto maingoes toorigin/main, not the local branch. That's the question Jujutsu raises for every commit, and the same answers would do. - Git's index after
sl amend. Git keeps the file as it was before the amend, staged, andgit-splicewarns about uncommitted changes. The fix belongs in Sapling (sapling#1316).git-spliceshouldn't reset the index, since staged changes are the user's. - A Sapling clone.
sl clonemakes a repository with no Git working copy, where Git commands don't work.git-spliceis out of reach there.
Sapling's records
.splice and Sapling's header record the same facts: the library's URL,
its commit, and the folder. In a Git repository, the header is called
test_subtree, and subtree.use-prod-subtree-key switches to subtree,
so the format may still change.
- Turn an import into a splice.
clone --from-submoduleturns a submodule into a splice. The same could read the folder's newest Sapling record and write.splicefrom it: the library's commit is the sync point, and nothing has to be fetched again. After that,pushsends the monorepo's fixes back, whichsl subtreecan't. - Read the record instead of
.splice.pushandpullneed only the sync point, the folder and the URL. They could take them from the newest Sapling record, so a folder imported withslsyncs both ways without a.splice. A squash merge drops the record, and an older one would give the wrong sync point, sogit-splicewould have to refuse where Sapling falls back. - Write the record too. A pull could add the header to its commit,
so a later
sl subtree mergestarts from it. Git can write such a commit (git hash-object -t commit), butgit commitcan't, and the header's format is Sapling's to change.