`git:`

Branch / commit / push strategy. Ops & reuse

Syntax

git:
  work on a branch
  commit when the goal is met
  open a pull request

What it does

A git: block sets the version-control strategy — how the loop branches, commits, and pushes. With no block at all, LoopFlow works on a branch, commits once when the goal is met, and does not push. A block refines any of three axes: where the work happens (work in place / on a branch / on a branch "name" / in a worktree); when it commits (commit when the goal is met / each cycle / each story / never); and whether it leaves the machine (push when done, then optionally open a pull request).

Reach for an explicit block when the default cadence doesn't fit the job. commit each cycle gives you a granular history (and easy rollback) while a loop iterates; commit each story lands one commit per stage of a pipeline; work in a worktree isolates a risky run from your working tree entirely. The block sits at one of two levels: at the config tier (top of the file, before any definition) it applies to every loop in the file; inside a loop body it refines just that loop. The cascade is lowest-wins — built-in default, then a repo-wide loop.config, then the file's block, then a per-loop block — so you set the broad policy once and override only where needed. One rule sits outside the cascade and cannot be overridden by any block: never push to main or master. A push when done aimed at a protected branch is an error that surfaces before the loop runs, not a surprise after.

Example

git:
  work on a branch
  commit when the goal is met
  push when done
  open a pull request

examples/git_policy.loop

How it runs

Three layers, each refining the one above. The protected-branch rule sits outside all of them: pushing to main/master is always refused.

Common mistakes

Expecting to push to main. push when done on main/master is refused unconditionally — no block can override it — and it fails up front, before the loop starts. Push a feature branch and open a pull request instead.
work in place + push when done on a protected branch. Same unconditional error: editing the current branch as-is and then pushing it, when that branch is protected, is caught before the run.
Misreading the cascade. Lowest wins — a per-loop block overrides the file block, which overrides loop.config. If a loop isn't committing the way you expect, check for a narrower block quietly overriding the broader one.
commit each cycle on a long loop. Great for granular history and rollback, but a thrashing loop can produce a noisy pile of commits. If that's not what you want, keep the default commit when the goal is met for a single clean commit.

git: