Cherry-pick a commit onto the current branch. On conflict git leaves the
cherry-pick in progress, so the error surfaces for the caller to tell the
user to resolve and git cherry-pick --continue.
Force-delete a branch. Use only once review state confirms it landed: a
squash merge leaves the commits non-ancestry-merged, so git branch -d
would refuse even though the work is in.
A unified-0 diff against HEAD: just the staged changes when cached,
otherwise all tracked changes (staged and unstaged). Zero context lines
so each hunk’s pre-image range pinpoints exactly the lines it touches.
Lines added and deleted in branch relative to base, over the symmetric
base...branch range a forge uses for a review diff (the branch’s own work
since it diverged). Binary files, which --numstat marks with -, count
as zero.
Refresh the remote-tracking refs (<remote>/<branch>) for branches that
exist on remote, in a single fetch. Branches absent from the remote (a
freshly created top of stack that was never pushed) are dropped rather than
failing the whole fetch. A no-op when none of them are on the remote.
Resolve path under the repo’s common git dir, which all linked
worktrees share, rather than the per-worktree dir git_path returns. Use
this for state that guards or mirrors the shared config (branch.*), so
every worktree of a repo agrees on one file.
Whether the working directory is inside a git work tree. Used for a clean
“not a git repository” message instead of letting git’s raw error surface
from the first command that needs the repo.
Force-push branches (with lease), returning the branches that actually
landed. Normally that is all of them; the exception is the merge-queue
backstop below, which drops a held-back branch from the returned set so the
caller never reports a branch as both held and pushed.
Rebase only the commits after base, replaying base..branch onto
parent. Used when the recorded fork point is known so commits that
landed upstream by squash or rebase are not replayed.
The commits tracking (a <remote>/<branch> ref) has that branch lacks
and that have no patch-equivalent already on branch - the commits a
force-push would silently drop, e.g. one committed straight on the host’s
web UI. (short-sha, subject) oldest-first, the order to cherry-pick them.
Empty in the normal post-rebase case, where every remote commit is
reproduced locally under a new hash.
Store content as a single-file commit and point reference at it, so the
data rides along a normal ref push. Orphan each time: the ref just moves to
the new commit (callers force-push it, as it is regenerable).