anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Jujutsu support? #3273

New Issue
Open
opened 2026-02-16 17:39:27 -05:00 by yindo · 12 comments
yindo commented 2026-02-16 17:39:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @beetleb on GitHub (Dec 2, 2025).

Originally assigned to: @rekram1-node on GitHub.

Question

Does anyone have experience using opencode with a Jujutsu repository? jj uses Git behind the scenes, so it's "compatible" with git - but my experiences are it doesn't always work well with coding agents.

If not, is there a way to use opencode without Git support (like I can with Claude Code)? By this I mean limiting Git usage to read only operations.

Originally created by @beetleb on GitHub (Dec 2, 2025). Originally assigned to: @rekram1-node on GitHub. ### Question Does anyone have experience using opencode with a Jujutsu repository? jj uses Git behind the scenes, so it's "compatible" with git - but my experiences are it doesn't always work well with coding agents. If not, is there a way to use opencode *without* Git support (like I can with Claude Code)? By this I mean limiting Git usage to read only operations.
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 2, 2025):

This issue relates to several existing discussions about OpenCode's Git dependency and version control support. Please check:

  • #3176: "Why is OpenCode massively abusing git?" - Documents excessive git operations and potential for performance issues
  • #3182: "Very slow session due to 98GB of git snapshots" - Related to git snapshot system without size limits
  • #1126: "Session grew to 88G!" - Uncontrolled git snapshot storage growth
  • #786: "opencode automatically creating git commits and coauthoring itself" - Shows automatic git operations without user control
  • #1445: "[Feature Request] Allow for setting read-only files and directories" - Requests read-only mode similar to your ask
  • #2365: "Not work in a git project, but normal work in a not git dir" - Shows OpenCode has issues in git directories
  • #2304: "OC fails with socket connection error when operating in a directory with a .git folder" - Indicates git folder dependency issues

These issues collectively suggest that OpenCode has a fundamental dependency on Git operations, including automatic snapshots and commits. Your feature request for Jujutsu support and read-only Git mode might benefit from the discussions in these threads, particularly regarding whether OpenCode can be designed to support alternative VCS systems.

@github-actions[bot] commented on GitHub (Dec 2, 2025): This issue relates to several existing discussions about OpenCode's Git dependency and version control support. Please check: - #3176: "Why is OpenCode massively abusing git?" - Documents excessive git operations and potential for performance issues - #3182: "Very slow session due to 98GB of git snapshots" - Related to git snapshot system without size limits - #1126: "Session grew to 88G!" - Uncontrolled git snapshot storage growth - #786: "opencode automatically creating git commits and coauthoring itself" - Shows automatic git operations without user control - #1445: "[Feature Request] Allow for setting read-only files and directories" - Requests read-only mode similar to your ask - #2365: "Not work in a git project, but normal work in a not git dir" - Shows OpenCode has issues in git directories - #2304: "OC fails with socket connection error when operating in a directory with a .git folder" - Indicates git folder dependency issues These issues collectively suggest that OpenCode has a fundamental dependency on Git operations, including automatic snapshots and commits. Your feature request for Jujutsu support and read-only Git mode might benefit from the discussions in these threads, particularly regarding whether OpenCode can be designed to support alternative VCS systems.
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 2, 2025):

I guess can you explain what you mean by without git support

@rekram1-node commented on GitHub (Dec 2, 2025): I guess can you explain what you mean by without git support
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 2, 2025):

and what your ideal situation is

@rekram1-node commented on GitHub (Dec 2, 2025): and what your ideal situation is
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@beetleb commented on GitHub (Dec 3, 2025):

Ideal: It understands the jujutsu version control (https://docs.jj-vcs.dev/latest/).

But what I can live with: A way to guarantee Opencode simply never modifies the git repository (no commit, no push, etc).

Right now I'm getting away with it because the default mode for jj is to put .git inside .jj, so git commands simply don't work unless you're in the .jj directory.

However, for projects where I'm working with others (who are using git), the .git directory is a sibling of .jj. If opencode then goes and modifies the git repo, it may make it harder to use jujutsu.

With Claude Code, I don't need to worry about it modifying the git repo. I'd like to have the same confidence in Opencode.

@beetleb commented on GitHub (Dec 3, 2025): Ideal: It understands the jujutsu version control (https://docs.jj-vcs.dev/latest/). But what I can live with: A way to guarantee Opencode simply never modifies the git repository (no commit, no push, etc). Right now I'm getting away with it because the default mode for jj is to put .git inside .jj, so git commands simply don't work unless you're in the .jj directory. However, for projects where I'm working with others (who are using git), the .git directory is a sibling of .jj. If opencode then goes and modifies the git repo, it may make it harder to use jujutsu. With Claude Code, I don't need to worry about it modifying the git repo. I'd like to have the same confidence in Opencode.
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 3, 2025):

Have you seen our permissions system?
https://opencode.ai/docs/permissions/

You can block git commands

I use "ask" for some see this:

  "permission": {
    "bash": {
      "rm*": "ask",
      "git push*": "ask",
      "git checkout*": "ask",
      "git commit*": "ask",
      "git reset*": "ask",
    },
  },
@rekram1-node commented on GitHub (Dec 3, 2025): Have you seen our permissions system? https://opencode.ai/docs/permissions/ You can block git commands I use "ask" for some see this: ``` "permission": { "bash": { "rm*": "ask", "git push*": "ask", "git checkout*": "ask", "git commit*": "ask", "git reset*": "ask", }, }, ```
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@beetleb commented on GitHub (Dec 3, 2025):

So is git usage coming entirely from the LLM, and not something opencode has in it?

I've set all of "bash" to "ask", so I guess I've got this covered.

@beetleb commented on GitHub (Dec 3, 2025): So is git usage coming entirely from the LLM, and not something opencode has in it? I've set all of "bash" to "ask", so I guess I've got this covered.
yindo commented 2026-02-16 17:39:27 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 3, 2025):

if you use git then opencode does do some git stuff internally but it doesnt change any of your files, we make a shadow git repo to try file changes and enable /revert but it won't or shouldnt mess with any of your stuff

@rekram1-node commented on GitHub (Dec 3, 2025): if you use git then opencode does do some git stuff internally but it doesnt change any of your files, we make a shadow git repo to try file changes and enable /revert but it won't or shouldnt mess with any of your stuff
yindo commented 2026-02-16 17:39:28 -05:00
Author
Owner
Copy Link
Copy Source

@arnold-c commented on GitHub (Dec 3, 2025):

I've been using JJ exclusively for the past 8-ish months with opencode, Claude (since 3.7), and Gemini (since 1.5) and have found the following things to be useful in directing the underlying LLMs to only use JJ commands. In general, they have gotten better as the models have progressed.

In my AGENTS.md file I have these lines

DO NOT make ANY git commands.
Use jj commands instead e.g., `jj describe -m "..."`, `jj log`, `jj status`, `jj diff` etc.

I also have some commands that are JJ specific, like creating a plan and then saving it to a markdown file before executing it.

---
description: Write a plan to a file and then complete it
temperature: 0.3
---

Ok. Write this plan to a file to provide checkpoints and reference back to it as you go
through the implementation. For each new step, use `jj new -m` to create a new blank jj
revision BEFORE starting the work, WITH a description of the work that will be done

or to add a revision description

---
description: JJ describe for the HEAD or the passed change ID
temperature: 0.3
---

You are working in a Jujutsu co-located repo.
You should provide comprehensive revision descriptions using `jj describe -m "..."`.
Provide a complete proposal for the revision: $ARGUMENTS and no other revisions.
You DO NOT need to check the jj log.
Then, check the changes in that revision using `jj show -r` on the revision specified.
Before making the change, ask for confirmation of the message.

DO NOT make ANY git commands. Use jj commands instead e.g., `jj describe -m "..."`, `jj log`, `jj status`, `jj diff` etc.
DO NOT run any code.
@arnold-c commented on GitHub (Dec 3, 2025): I've been using JJ exclusively for the past 8-ish months with opencode, Claude (since 3.7), and Gemini (since 1.5) and have found the following things to be useful in directing the underlying LLMs to only use JJ commands. In general, they have gotten better as the models have progressed. In my AGENTS.md file I have these lines ``` DO NOT make ANY git commands. Use jj commands instead e.g., `jj describe -m "..."`, `jj log`, `jj status`, `jj diff` etc. ``` I also have some commands that are JJ specific, like creating a plan and then saving it to a markdown file before executing it. ``` --- description: Write a plan to a file and then complete it temperature: 0.3 --- Ok. Write this plan to a file to provide checkpoints and reference back to it as you go through the implementation. For each new step, use `jj new -m` to create a new blank jj revision BEFORE starting the work, WITH a description of the work that will be done ``` or to add a revision description ``` --- description: JJ describe for the HEAD or the passed change ID temperature: 0.3 --- You are working in a Jujutsu co-located repo. You should provide comprehensive revision descriptions using `jj describe -m "..."`. Provide a complete proposal for the revision: $ARGUMENTS and no other revisions. You DO NOT need to check the jj log. Then, check the changes in that revision using `jj show -r` on the revision specified. Before making the change, ask for confirmation of the message. DO NOT make ANY git commands. Use jj commands instead e.g., `jj describe -m "..."`, `jj log`, `jj status`, `jj diff` etc. DO NOT run any code. ```
yindo commented 2026-02-16 17:39:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 3, 2025):

You could also create a tool plugin that intercepts bash invocations, detects if it's running a git command and then throw an error saying to user jj instead, that'd really force it

@rekram1-node commented on GitHub (Dec 3, 2025): You could also create a tool plugin that intercepts bash invocations, detects if it's running a git command and then throw an error saying to user jj instead, that'd really force it
yindo commented 2026-02-16 17:39:28 -05:00
Author
Owner
Copy Link
Copy Source

@dpshade commented on GitHub (Dec 30, 2025):

Working on a dedicated JJ plugin that may help! https://github.com/dpshade/jj-opencode

@dpshade commented on GitHub (Dec 30, 2025): Working on a dedicated JJ plugin that may help! https://github.com/dpshade/jj-opencode
yindo commented 2026-02-16 17:39:28 -05:00
Author
Owner
Copy Link
Copy Source

@TomLucidor commented on GitHub (Jan 20, 2026):

@arnold-c how is jj in relations to this "Git Worktree" thing that some are talking about? Are they related in what they solve?

@TomLucidor commented on GitHub (Jan 20, 2026): @arnold-c how is `jj` in relations to this "Git Worktree" thing that some are talking about? Are they related in what they solve?
yindo commented 2026-02-16 17:39:28 -05:00
Author
Owner
Copy Link
Copy Source

@arnold-c commented on GitHub (Jan 26, 2026):

@TomLucidor I don't want to take us off on too much of a tangent to the issue here as that's not great for everyone who's involved in this issue and get notifications, but I will say that I just find JJ generally easier to work with than Git and all my projects use JJ now. I find jj undo and the oplog and evolog easier to work with than the reflog in git.

The main use of worktrees I've found is to avoid having to deal with stashes when you have to switch tasks and are maintaining a branch-per-feature approach to development (this post provides a decent overview of the motivations and use-case). However, I never really got along with that as I found that it is too much overhead for the work I typically do (managing stash or just placing a WIP commit that you amend isn't too hard), and the LSPs I typically use (90% Julia) don't do well with worktrees.

Steve Klabnik has an excellent online book/resource for JJ, and this page describes how you can achieve something that's a little similar to work on all branches simultaneously, but I haven't had a need to go that far - I can typically get away with just making edits in a single branch and using jj split -i (or jj squash -i, if working above an empty change to emulate the git staging area) to break things up as necessary. This is another good example of how you could replace worktrees with JJ, or, really, makes it easier to do feature branch approach if that's required (or just because you like that). This discussion in the JJ github is worth skimming to figure out what kind of workflow might work for you and your problems.

Anyway, to try and keep this issue on track for those that are working on it I think it's probably best to not continue this discussion further, but hopefully this is enough info to answer your questions and get you going in the right direction when it comes to looking into JJ.

@arnold-c commented on GitHub (Jan 26, 2026): @TomLucidor I don't want to take us off on too much of a tangent to the issue here as that's not great for everyone who's involved in this issue and get notifications, but I will say that I just find JJ generally easier to work with than Git and all my projects use JJ now. I find `jj undo` and the `oplog` and `evolog` easier to work with than the `reflog` in git. The main use of worktrees I've found is to avoid having to deal with stashes when you have to switch tasks and are maintaining a branch-per-feature approach to development ([this post](https://andrewlock.net/working-on-two-git-branches-at-once-with-git-worktree/) provides a decent overview of the motivations and use-case). However, I never really got along with that as I found that it is too much overhead for the work I typically do (managing stash or just placing a WIP commit that you amend isn't too hard), and the LSPs I typically use (90% Julia) don't do well with worktrees. Steve Klabnik has an excellent online book/resource for JJ, and [this page](https://steveklabnik.github.io/jujutsu-tutorial/advanced/simultaneous-edits.html) describes how you can achieve something that's a little similar to work on all branches simultaneously, but I haven't had a need to go that far - I can typically get away with just making edits in a single branch and using `jj split -i` (or `jj squash -i`, if working above an empty change to emulate the git staging area) to break things up as necessary. [This](https://flames-of-code.netlify.app/blog/my-jj-workflow/) is another good example of how you could replace worktrees with JJ, or, really, makes it easier to do feature branch approach if that's required (or just because you like that). [This discussion](https://github.com/jj-vcs/jj/discussions/2425#discussioncomment-9193689) in the JJ github is worth skimming to figure out what kind of workflow might work for you and your problems. Anyway, to try and keep this issue on track for those that are working on it I think it's probably best to not continue this discussion further, but hopefully this is enough info to answer your questions and get you going in the right direction when it comes to looking into JJ.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3273
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?