git: cherry-pick, rebase and pull --rebase

docs/13_git_interface.md lists cherry-pick and revert as "out of scope until a concrete caller needs them." Here is one.

Use case

A long-lived checkout on a shared branch, with local commits that are not pushed yet, while other clients push to the same branch. Catching up with merge or pull adds a merge commit every time and makes the history non-linear. What a developer does here is git pull --rebase: the local commits exist nowhere else, so replaying them on top of the upstream rewrites nothing shared, and the history stays linear.

Ask

1. cherryPick on the client, and git cherry-pick <oid> in the shell. isomorphic-git already ships cherryPick (a three-way merge against the commit's own parent, applied to the working tree), so this is a wrapper in the shape of merge.
2. rebase on the client, with git rebase <upstream> and git pull --rebase in the shell: reset the branch to the upstream and cherry-pick upstream..HEAD oldest first, stopping on a conflict with the paths reported as merge reports them. --autostash would be welcome, since stash is already there.
3. revert, if you want to close the set.

Related

isomorphic-git's merge writes the merged tree and the commit and moves the branch, but on a clean merge it does not update the working directory; only pull runs a checkout afterwards. Through the client, a clean merge therefore leaves every file it changed reading as a local modification back to the old content. Worth a line in the docs.

Environment

@cloudflare/computer 0.3.0 (pkg.pr.new build 9184be3), isomorphic-git 1.38, Workers runtime.