Does sugar manage git branches and/or worktrees?

[ben-elliot-nice]

I just found this project and it looks like exactly what i've been looking for.

I will have time to try it out myself in the next 1-2 days.

In the meantime - just wondering how this extension managed git branching and/or worktrees?
A quick cursory search indicates it's only checking things like git status so maybe the asusmption is that you've managed the git branch/worktree state before invoking sugar?

In either case - is it possible to have sugar in mutiple claude code sessions in the some git repo working on different sets of queues?

[cdnsteve]

Short answer: Sugar manages git branches (partially) but not worktrees. Running multiple Sugar sessions in one repo working directory at the same time is not safe.

Worktrees: no

Sugar never calls git worktree. There are zero references to worktrees anywhere in the codebase. All git operations run against the current working directory (cwd=self.repo_path in GitOperations). So your assumption is correct: Sugar works on whatever repo you invoked it in. It does not spin up isolated worktrees.

Branches: only conditionally, and only for GitHub-sourced work

Sugar has two git workflow modes, set in config under sugar.discovery.github.workflow.git_workflow:

• direct_commit (default): Sugar does not manage branches at all. It commits straight to whatever branch you are currently checked out on. You are expected to have set up the branch yourself.
• pull_request: For work that comes from a watched GitHub issue, Sugar creates a feature branch (sugar/issue-{N} by default) off a base branch, commits to it, pushes it, and opens a PR.

The branch creation (git_operations.py, create_branch) does this:

git checkout <base_branch>
git pull origin <base_branch>
git checkout -b <branch_name>

Important detail: that git checkout <base_branch> mutates your working tree. Sugar switches the repo off whatever you were on and onto the base branch before creating the feature branch. On a failed workflow it switches back to the base branch. So the branch handling only fires for GitHub-issue-sourced work in PR mode, not for tasks you queued locally.

Multiple sessions in the same repo: not with the current design

The git operations share a single working tree, and there is no file locking or mutex around them. Git's checkout is global to the repo. If two Sugar sessions are pointed at the same working directory and one does git checkout sugar/issue-42, it changes the files the other session is editing too. They will fight over the shared .git and working tree.

So for your "multiple Claude Code sessions on different queues in the same git repo" case, the safe setup today is:

• Give each Sugar session its own checkout (a separate clone, or a git worktree you create yourself outside of Sugar), or
• Only run one Sugar session per repo working directory at a time, or
• Keep Sugar on direct_commit and let each Claude Code session manage its own branch/worktree manually before invoking Sugar.

The cleanest path if you want true concurrency on one repo is exactly what you guessed Sugar should be doing: create the worktrees yourself and run one Sugar process per worktree. Sugar will happily operate inside a worktree directory, it just will not create one for you.

---

This is current as of the develop branch (v3.9.x). The branch/workflow code lives in sugar/utils/git_operations.py and sugar/core/loop.py if you want to read it directly.