Module worktree_copy_error 

The one failure type of the linked-worktree ignored-state copy and its diagnostics. What: The one failure type of the linked-worktree ignored-state copy, with the complete user-facing diagnostic in its message. Why: Every copy step fails with a message that names the path it could not handle and, when there is one, the operating system’s cause. The incumbent renders the cause after the message with a fixed separator, so both wrappers print the same words.

In TS you’d write (pseudocode):

class WorktreeCopyError extends Error {
  constructor(message: string, cause?: unknown) { super(`${message}${causeSuffix(cause)}`); }
}

Structs

WorktreeCopyError

What: One copy failure and its complete diagnostic. Why: Callers print the message unchanged; the lifecycle decides the exit status.

Constants

AUTOMATIC_FAILURE_MESSAGE

What: The generic message the lifecycle reports for a failure that is not already a copy failure. Why: The incumbent’s asWorktreeCopyError wraps unknown failures with this exact sentence.

Functions

failure_with_cause

What: The diagnostic of one failed step: its message, then the cause when one exists. Why: A cause is appended exactly once, after the separator the incumbent uses.

is_raw_failure

What: Whether a failure is raw text that an enclosing wrapper still has to word. Why: The incumbent wraps only failures that are not already its own WorktreeCopyError, and cli-git’s own messages always start with its prefix.

lifecycle_failure

What: The lifecycle’s wording for a raw failure that reached the top of a copy. Why: The user sees the generic sentence once, with the underlying cause after it.

raw_failure

What: A failure from the operating system or from a process, carried as its own text with no wrapper sentence. Why: Every step that does not own a wording of its own leaves the raw text to the nearest enclosing wrapper. Messages cli-git owns always start with cli-git:, so a raw text can be told apart without another flag.

wrap_raw

What: Words a raw failure with the given message, and leaves an owned failure as it is. Why: Each wrapping step names the input it was handling, and never hides a message cli-git already wrote.