## PromoteReport


Result of `Repo.apply_promote`.


Usage

``` python
PromoteReport(
    fast_forwarded=dict(),
    merged=dict(),
    skipped=list(),
    refused=dict(),
    held=dict(),
    conflicts=dict(),
    kept_forks=dict(),
    trunk_moved=None,
    trunk_held=None,
    plan=None
)
```


## Parameter Attributes


`fast_forwarded: dict[str, State] = dict()`  
Key -\> the base branch's new state after a fast-forward.

`merged: dict[str, State] = dict()`  
Key -\> the base branch's new state after a native merge.

`skipped: list[str] = list()`  
Keys whose base already matched the target, or that had nothing to promote.

`refused: dict[str, str] = dict()`  
Key -\> why tether would not move the base (with the system's own recipe).

`held: dict[str, str] = dict()`  
Key -\> what would have happened: a fast-forward or merge not performed because another object was refused and no keys were named. A bookmark is planned whole or not at all; the plan is the atomic unit - once applying, each system's fast-forward stands on its own (see the caveats).

`conflicts: dict[str, list[str]] = dict()`  
Key -\> conflicting units reported by a merge that was rolled back.

`kept_forks: dict[str, str] = dict()`  
Key -\> why the working branch was not reset onto a merge result: it gained writes between the plan and the merge, and those are never discarded; commit them and promote again.

`trunk_moved: str | None = None`  
The commit the trunk bookmark now points at, when every promoted object fast-forwarded and nothing was refused: the bookmark's commit describes what the upstream branches now hold, so `main` is set to it.

`trunk_held: str | None = None`  
Why the trunk bookmark was left where it is although the data landed: it gained commits since the plan, and it is never moved backwards.

`plan: Plan | None = None`