Overview

Lazygit's state–intent–feedback model treats files, patches, commits, branches, and worktrees as different instances of one reasoning loop. Observe the relevant state, select the smallest meaningful intention, transform it into the right Git operation, apply it, and verify the refreshed result. Naming the destination clarifies whether the index, history, topology, or remote will change. The model exposes interruptions and evidence limits without turning verification into a guarantee of semantic correctness.

Learning outcomes

The reliable loop is observe, select, transform, apply through Git, and verify the refreshed state.
Naming the destination—index, history, worktree, or remote—clarifies what an action will change.
Feedback reports repository state, but semantic correctness and collaboration consequences still require human review.

Keywords

LazygitGitStateIntentFeedbackVerification

A Working Model: State, Intent, and Feedback

Lazygit becomes easier to reason about when files, patches, and commits are treated as instances of one loop rather than as unrelated features. This chapter connects the earlier state model, precise patch selection, and history editing into a practical test: observe the repository, select an intention, transform that intention into the right Git operation, apply it, and verify the refreshed state. The value of the model is that it tells the reader where to look before pressing a key and where to remain skeptical after the screen changes.

The five steps are short, but they are not interchangeable. Observation without selection is only browsing. Selection without a clear intention is a cursor position. Transformation is the point where a file line becomes a patch or a commit choice becomes a rebase action. Application is where Git changes the working tree, index, references, or operation state. Verification is where the user reads the result and decides whether it proves enough to continue. Most mistakes happen when two of these steps are mentally collapsed—for example, treating a highlighted line as though it has already been staged, or treating a completed rebase as proof that the new history is correct.

flowchart LR A["Observe repository state"] --> B["Select intent"] B --> C["Transform selection"] C --> D["Apply through Git"] D --> E["Verify refreshed state"] E --> A

One loop, two kinds of change

Take a working copy containing a new function, an unrelated documentation correction, and a test adjustment. Observation begins with the Files view: the user sees that the file is changed and can inspect the staged and unstaged comparisons. Selection narrows the subject to the lines that belong to the function. Intent gives the selection a purpose: prepare that function for the next commit while leaving the documentation and test changes available for separate decisions.

Transformation is what prevents this from being a mere visual choice. The selected lines become an inclusion decision in the patch builder. Unselected additions are removed from the generated patch, while unselected old-file lines may remain as context so Git can locate the selected change. The hunk is recalculated to describe the transformed patch. Application crosses the real repository boundary when Git places that patch into the index. Verification then compares the staged and unstaged views. The staged view should contain the function change; the unstaged view should still expose what was intentionally left behind.

Now compare that with a reviewer asking for a correction to an older commit. The visible subject is no longer a working-tree line alone. The user must observe the commit graph and the relevant commit's content, select the change that corrects it, and decide whether the intent is “make this old commit absorb the change” or “record a reviewable correction that will be autosquashed later.” The transformation is a fixup, amend, or custom patch operation rather than ordinary index staging. Application may start an interactive rebase, stop at a commit, amend it, and continue. Verification is a graph and content inspection: does the correction sit where it belongs, and is the branch still in a state the user recognizes?

The two cases differ in destination, not in the basic reasoning. In the first, the selected change crosses into the index. In the second, it may cross into an older commit or remain as a separate fixup until review is complete. The patch and history mechanisms are connected because both preserve a distinction between the user's selected intent and the broader set of changes visible around it.

Published by DeepMox

FAQ

Which Git state should a Lazygit action change?

The action should change the state named by the user's intention: the index for partial staging, history for a fixup or amend, topology for worktrees, or a remote for collaboration. Naming that destination makes the consequence concrete.

How does the state–intent–feedback model apply to branches and worktrees?

It applies by observing branch relationships and worktree locations, selecting the change stream, applying a topology action, and verifying local and remote-facing effects. The carrier changes, but the reasoning loop remains.

When should a Lazygit user escalate to the Git CLI?

Escalate when a transition is public, permanent, ambiguous, outside Git's recorded model, or requires evidence the interface cannot supply. The CLI is an option when the visible workflow no longer provides enough control or proof.

Previous11 minLazygit: Reviewable History Rewrites

Next10 minLazygit: Worktrees, Stacks, and Branches

Lazygit: The State–Intent Loop

A Working Model: State, Intent, and Feedback

One loop, two kinds of change

FAQ