Git Machete

git-machete

git machete is a logic- and feature-heavy CLI for managing chains of branches, but it keeps almost no extra state of its own: the only user-visible file it owns is .git/machete (the "branch layout" - a tree of branches with parent/child relationships, fork points and PR/MR annotations). It also maintains a transparent merge-base cache for performance, which the user never needs to touch. Everything else - rebases, merges, pushes, status rendering, PR/MR creation - is driven straight off git and the hosting API.

If the repo has no .git/machete file yet (check with git machete file && test -s "$(git machete file)"), the layout has not been initialized: run git machete discover -y (or ask the user) before anything else.

Do not run git machete discover against an already-initialized layout unless the user explicitly asks for it. discover re-derives the entire layout from heuristics (recent commit dates, branch reachability) and silently overwrites any hand-curated ordering, parenting, or annotations the user has built up. Use the targeted commands (add, slide-out, hand-edit) for incremental changes.

Hard rules - read first

1. Prefer dedicated subcommands over hand-editing .git/machete when one fits the task. You can edit the layout file directly, but parse errors are quiet, so reach for a subcommand whenever there is one that fits:

   • git machete add [-y] [<branch>] [--as-root|--onto <parent>] - add a branch
   • git machete slide-out [<branch>...] - remove a branch and re-parent its children (non-interactive by default; see rule 4 for --delete)
   • git machete anno [<text>] - set/clear annotation on the current branch
   • git machete rename <new-name> - rename a local branch and its layout entry (use this instead of git branch -m)

   The layout file grammar is small: one branch per line, each child indented one level deeper than its parent, with an optional annotation after whitespace on the same line. Any consistent indent unit works (a tab or N spaces), but the same unit must be used throughout the file.

   For operations with no dedicated command (e.g. reparenting an existing branch, splitting one branch into two, ad-hoc reordering of siblings), hand-edit .git/machete directly. The file is small and brittle: edit it in place with the agent's structured editing tool (StrReplace / equivalent string-replacement primitive), not by piping it through sed/awk or rewriting it from a shell heredoc - one stray space changes the parent/child relationship silently. Recommended sequence:

   1. MACHETE="$(git machete file)" - resolve the actual path (worktree/submodule-aware).
   2. cp -a "$MACHETE" "$MACHETE~" - back up; the file is NOT tracked by git, so this is your only undo.
   3. Read the file, perform a structured in-place edit (preserve the existing indent unit), write it back.
   4. git machete status - verify the parse. If it errors, restore with cp -a "$MACHETE~" "$MACHETE".

   When indenting, match the unit already used in the file (could be a tab or any number of spaces, but it must stay consistent throughout). For a brand-new layout, use two spaces.

   In the common case the layout file lives at .git/machete and hard-coding that is fine. The two exceptions are submodules (.git/modules/<path>/machete) and linked worktrees with git config machete.worktree.useTopLevelMacheteFile false (.git/worktrees/<wt-name>/machete); when in doubt, git machete file always resolves correctly.

2. Register every new branch in the layout. Whenever you create a branch as part of the user's actual work (git checkout -b ..., git switch -c ..., git branch ...), follow it with git machete add -y [--onto <parent>] so the new branch joins .git/machete. In a git-machete-managed repo, the layout is the index of "branches I care about": users typically keep every branch they actively touch under git-machete, and the only branches deliberately left out are unrelated ones (someone else's WIP, throwaway branches checked out for a quick look). Defer to the user if they ask you to leave a branch unmanaged - but don't silently skip the add step; ask if you're unsure.

3. Never invoke a command that reads stdin without -y/--yes. Commands with a -y/--yes flag: add, advance, clean, delete-unmanaged, discover, traverse, github create-pr, gitlab create-mr. Always pass -y from a non-interactive context (CI, agent, script).

4. Some commands prompt and have no -y to suppress it - avoid or work around them:

   • git machete update - prompts only if the current branch is missing from the layout. Workaround: git machete add -y first, then git machete update.
   • git machete status - prompts to slide out stale branches when stdout is a tty. Workaround: pipe through | cat or redirect, or use git machete status --color=never > /tmp/status.txt.
   • git machete slide-out --delete ... - prompts once per branch and the prompt can't be silenced. Workaround: run plain git machete slide-out <branch>... first, then git branch -D <branch>... yourself (or skip the --delete entirely). Plain slide-out (and slide-out --removed-from-remote) is non-interactive.
   • git machete go without a direction - opens an interactive single-keystroke picker. Never invoke this form from an agent. Use git machete go <direction> (up/down/prev/next/root/first/last) instead, which is non-interactive (but may still prompt if down is ambiguous - prefer git machete show down | head -1 for scripted child discovery).
   • git machete edit - opens $EDITOR. Never invoke this form from an agent. Use the dedicated subcommands from rule 1, or hand-edit .git/machete for the cases that have no subcommand.

5. Plumbing commands have stable output across minor versions and are safe for scripting. Use these for any "I need to read state from git-machete" task:

   • git machete file - absolute path of .git/machete
   • git machete fork-point [--inferred] [<branch>] - prints fork-point SHA on stdout (and only that)
   • git machete is-managed [<branch>] - exit code 0 if managed, non-zero otherwise; no stdout
   • git machete list <category> [<branch>] - newline-separated branch names; categories: managed, addable, childless, slidable, slidable-after <branch>, unmanaged, with-overridden-fork-point
   • git machete show <direction> [<branch>] - newline-separated branch names for the given direction
   • git machete version - prints git-machete version X.Y.Z

   All other commands' stdout/stderr formatting may change between minor versions, including status.

6. To open a PR/MR, use git machete github create-pr -y (or gitlab create-mr -y), not raw gh pr create / glab mr create. The machete subcommand does three things the hosting CLI doesn't:

   • sets the PR/MR base to the branch's parent in the layout, not the repo default branch (correct for stacked PRs);
   • writes the new PR/MR number back onto the branch in .git/machete so subsequent status / traverse / retarget-{pr,mr} see it;
   • uses .git/info/description for the default PR title.

   The host's own CLI is only the right tool for things git-machete doesn't cover (read-only listing/commenting, deleting a PR, fetching CI status, etc.). See the Create / restack / retarget PRs recipe.

7. Resolve yellow edges before running update/traverse. A yellow edge means a child branch is a descendant of its parent but git-machete's inferred fork point lies somewhere earlier than the parent tip - usually because the branch was rebased over commits from another branch, or its real parent is a different managed branch. In ASCII-only output the edge marker is ?- (e.g. ?-feature-x); with colour it's yellow. Do not run git machete update / git machete traverse blindly in this state - a rebase from the inferred fork point will pull extra commits onto the branch.

   Instead, run git machete status --list-commits --color=never | cat (which prints the relevant suggestion under the tree) and present the options to the user. The three resolutions, in roughly the order to consider them, are:

   • git machete fork-point <branch> --override-to-parent - accept the parent branch tip as the fork point (use when the branch was rebased and the inferred fork point is stale).
   • git machete update (rebase) - only after confirming the inferred fork point really is correct and the extra commits should be re-applied.
   • Reattach the branch under a different parent (e.g. hand-edit .git/machete as in rule 1) - use when the layout is wrong and the branch's real parent is a different managed branch.

   Pick based on what the user wants; don't auto-choose.

Command catalog with side effects

The table lists every non-deprecated top-level command and github/gitlab subcommand. The brace notation {github,gitlab} verb-{pr,mr} is shorthand for the pair github verb-pr and gitlab verb-mr.

Commands absent from every row (completion, diff, help, log, plus the plumbing commands listed above, plus {github,gitlab} update-{pr,mr}-descriptions which only talks to the hosting API) do not satisfy any of these properties.