Report what the rebase in repo is currently doing.

Call this before amending, continuing or resolving. In particular head_is_replaying_commit distinguishes a stop where the commit was applied from one where it conflicted part-way, which git's own output does not.

Report each conflict as what the two sides did, rather than as markers.

Per contested region you get two diffs from the common base: one for the branch built so far, one for the commit being replayed. Read them as two intents and compose them -- "wrap this block in an if" plus "swap this call" is usually just both.

Regions only one side changed are not listed: git merged those already.

context is how many unchanged lines to show around each change. Raise it when the region is hard to place -- which function it is in, whether the lines above already do what the replayed commit is adding. Set include_full_sides for the three whole texts when even that is not enough.

Stage the resolved content for one conflicted path.

Three ways, in rough order of how much they cost to use:

• take="both", "branch" or "replaying" resolves every conflict block in the file the stated way. "both" keeps the branch's lines then the replayed commit's, which is what two insertions at the same point almost always mean. Cheapest, and it cannot introduce a typo.

• no arguments stages what is already in the working tree, for a file large enough that sending it back costs more than editing it in place.

• content writes the finished file and stages it.

Every route refuses content that still contains conflict markers. Staging one is how a commit ends up with <<<<<<< in it, and nothing downstream catches that.

Read the steps a running rebase has left, or replace them.

Worth having because the need shows up mid-run: a fixup turns out to depend on a commit scheduled after it, and the fix is to move one line rather than to abandon thirty resolved conflicts and start again.

Replacing the list can drop commits exactly as writing one badly can, so the same check applies: a commit in the remaining steps and not in the replacement is refused unless force. Lines that name no commit -- exec above all -- are counted too, and dropping every exec silently turns off the per-commit check, so that is called out rather than assumed.

Check what a rebase would do, without starting it or changing anything.

Reports commits the todo would drop silently, commits it names that are not in the range, commits whose change is already in the base under a different sha, anything already in progress or uncommitted, and untracked files a replayed commit would collide with.

Begin a rebase onto base, and report where it stops.

Refuses anything rebase_preflight called unsafe, unless force. Before starting it tags the current tip, so the result can be checked against it, and moves aside untracked files a replayed commit would collide with.

autosquash folds every fixup! and squash! in the range into the commit its subject names, which is the workflow git commit --fixup sets up. It cannot be combined with a todo, since it is a way of generating one.

check_command is run after every commit, which is the only thing that catches a step that applies cleanly but leaves the tree broken.

auto_resolve composes conflicts where the two sides touched different lines and carries on without stopping. Off by default: lines that do not overlap can still contradict each other -- one side adding a call, the other removing the helper it needs -- and a conflict resolved without being read has to be reviewed afterwards anyway. Use it when replaying a branch whose conflicts you already understand.

Amend the commit this rebase has just applied.

Refused at every other kind of stop. At a conflicted stop the commit being replayed has not been created yet, so HEAD is still the one before it and amending would fold two commits into one -- silently, and reported by git as success.

stage_tracked stages modifications to files git already tracks. It will not add untracked files: those are never part of what a rebase is rewriting, and sweeping them in is how a stray binary or somebody's local notes end up in history.

Carry on with the rebase, and report where it stops next.

Refused while any path is still unmerged, which is the other way a marker reaches a commit.

auto_resolve behaves as it does in rebase_start, and is off for the same reason: deciding a conflict without reading it is not this tool's job.

Check the finished rebase against the tip it started from, and tidy up.

What must stay the same is the change the branch makes to its base -- not the resulting tree, which legitimately changes when the rebase also moves onto newer upstream work. A difference here is a report of damage: a commit dropped from the todo, or a conflict resolved the wrong way. Every rewritten commit is also scanned for conflict markers, since one committed part-way and tidied up later still leaves a commit nobody can build.

The backup tag is kept either way; deleting the only record of where the branch was is not this tool's decision to make.

Drop the commit being replayed and carry on.

For a commit whose change is already in the base under a different sha, or one whose conflict resolves to "the branch already says this". Git offers it at every conflict; without it here the only way to take that offer is to reach past these tools and run git by hand, which is how a rebase ends up half driven from each side.

Refused when nothing is being replayed: skipping is a decision about a commit, and at a break or a failing exec there is no commit in question.

Abandon the rebase and put back anything that was moved aside.