5 ms·

VisualJJ – Jujutsu in Visual Studio Code

181 points by demail 8mo ago

viraptor 8mo ago
It does look nice, I'll give it a go. Just wanted to say that "Git-out-of-the-way source control" is the best tiny description of JJ I've ever seen, because it's both true and the pun works perfectly. It brought me joy.
- AbuAssar 8mo ago
  it is worth noting that Jujutsu uses Git’s storage, networking, and ecosystem.
  - SAI_Peregrinus 8mo ago
    Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.
    - capitainenemo 8mo ago
      Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues referenced in a jujutsu intro guide last year linked on HN) The same issue hit the initial efforts (that I think were the inspiration for jj) when the mercurial folks, recognising git had kinda taken over the market, experimented in making a mercurial frontend backed by the git db. Limitations like the diff format (mercurial's weave one is one the jj folks also want to add at some point) and the lack of a method for tracking phases (mercurial relies on this for clean history without throwing out commits), and lack of file move/copy tracking.
      - gcr 8mo ago
        This comment made me reconsider my attitude about git a little bit. Thank you.
  - steveklabnik 8mo ago
    It uses it when you use the git backend, but not when you don’t. Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.
    - tuwtuwtuwtuw 8mo ago
      For anyone that does not work at Google, it sounds like an implementation detail that does not matter.
      - steveklabnik 8mo ago
        Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git. To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's useless. jj is still pre-1.0 software, there's a lot more work to do, and more interesting things coming down the pipeline. That matters, even if it's not relevant to every potential user just yet.
        minraws 8mo ago
        10 years of using Git and I never knew undo was what I craved. And the ability to rebase and edit commits in a single command. Solves 90% of my problems so haven't felt like I needed any additional tooling on top of jj. But I am curious is there some edge case on jj that I missed. That you folks are working on improving tooling for? Just really curious about this new world with some better solutions to git. I liked pijul a bunch too but lack of compat with git meant I can't use it for work... Haha real sad moment right there.
        Zacharias030 8mo ago
        Not working on it (yet), but I wish the jj <-> github story was a little more ergonomic. Additionally, I am really missing support for stacked diffs, ie, easily pushing a number of commits into one PR on github each such that they all show their incremental diff. ezyang's gh stack was pretty useful, if a little bit fragile [0] and graphite.dev is also very nice, but paid software with a strong VC based motivation to become everyone's everything instead of a nice focused tool. [0] https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack I'm also not super happy with the default 3-way merge editor, but often cannot use vscode or other GUIs.
lima 8mo ago
There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk https://github.com/keanemind/jjk
- KingMob 8mo ago
  jjk caused a lot of problems for me when using multiple agents. It's running some sort of jj command that snap-shotted stuff and caused divergence (might have benefited from `--ignore-working-copy`). Not sure what the precise details were, but I gave up and uninstalled it after a week.
  - dwattttt 8mo ago
    Multiple agents is definitely tempting fate. Concurrent modification of the same git repo by multiple entities? At that point you should use multiple repos so they can merge & resolve. EDIT: of course, if a single agent uses git to modify a repo instead of jj, jj may have trouble understanding what's happened. You could compare it to using an app that uses an sqlite db, and then also editing that db by hand.
    - gcr 8mo ago
      The OP is talking about the `jj workspace create` command, which creates a separate working copy backed by the same repository. It’s not a bad way to work with multiple agents, but you do have to learn what to do about workspace divergence. Like git, you don’t lose any history.
    - KingMob 8mo ago
      Sibling comment from gcr has the right details. This doesn't involve git use at all. Even with multiple workspaces (like git worktrees), once you use something like jjk, both the agent and jjk in the associated VS Code are operating on the same workspace, so that doesn't isolate enough. I don't think jjk uses `--ignore-working-copy` for read-only status updates, so it's snapshotting every time it checks the repo status while the agent is editing. On top of that, throw in whatever Claude does if you "rewind" a conversation that also "reverts" the code, and agents wrongly deciding to work on code outside their focus area. It's possible watchman helps (I need to look into that), but I'm so rarely using jj in VS Code (all I really want is inline blame), that it was easier to remove jjk than try to debug it all. Divergence won't hide or lose any work, but it's an annoying time-suck to straighten out.
hirako2000 8mo ago
Just me or does sit well to monetize _mostly_ off the core benefits of an open source application? Can't be easy to build a GUI on top, but I'm sure a 10% revenue to be redistributed to the hero behind jj would go a long way. Would also pay off.
- throwatdem12311 8mo ago
  There is nothing about neither the licensing of jj or the spirit of open source that stigmatizes this.
  - hirako2000 8mo ago
    Nothing against, I agree.
- Valodim 8mo ago
  The hero behind jj is employed by Google afaik, so we're good.
- misnome 8mo ago
  10% revenue to google?
  - hirako2000 8mo ago
    Touché
  - surajrmal 8mo ago
    While the primary maintainer is a Google employee, the majority of commits and committers are not. It's decidedly not a Google project.
    - 3eb7988a1663 8mo ago
      I mean the Google CLA kind of says otherwise.
olup 8mo ago
I wanted the same extension but more steerable and open source, so I built open jj recently https://github.com/olup/open-jj https://github.com/olup/open-jj
- IshKebab 8mo ago
  You gotta put screenshots in the readme!
Okkef 8mo ago
I worked with JJ for half a year, and it was great. However, I've since decided to go back to GIT because of compatibility with existing workflows and AI tools. Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fall back to git too often.
- Yeroc 8mo ago
  Seeing similar comments across different articles and technologies and it makes me wonder how much AI is going to hold back the adoption of new technologies going forward.
  - hippo22 8mo ago
    I agree it will hold back new technologies, but, at the same time, I'm not sure what the value add of new technologies will be going forward. Often, as is the case with git vs. jj, the value add of a new technology is mostly ergonomic. As AI becomes more ingrained in the development flow, engineers won't engage with the underlying tech directly, and so ergonomic benefits will be diminished. New technologies that emerge will need to provide benefits to AI-agents, not to engineers. Should such a technology emerge, agent developers will likely adopt it. For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.
    - surajrmal 8mo ago
      Even if you're not authoring changes as much, change management is likely still to be a very useful activity for a long while. Also note that not everyone is using AI today, and many that do only use it as glorified auto complete. It will take many more years for it's adoption to put us in a situation like your describing, why halt progress in the meantime? My personal productivity increased greatly by switching to jj, perhaps more than adding Gemini CLI to my workflow. I can more confidently work on several changes in parallel while waiting on things like code review. This was possible before but rebasing it and dealing with merge conflicts tended to limit me from doing it beyond a handful of commits. Now I can have 20+ outstanding commits (largely with no interdependencies) and not feel like I'm paying much management overhead while doing so. I can also get them reviewed in parallel more easily.
SkoogyDan 8mo ago
There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui https://github.com/idursun/jjui
- surajrmal 8mo ago
  I love jjui, but I feel like it's also the reason I still use him over vscode. If you already use vscode, doesn't using a vscode extension make more sense?
  - SkoogyDan 8mo ago
    Of course there are some people that will want a gui not matter what. Then an extension or separate program is the only thing you can do. But i think it is really nice to have the same tool available everywhere, also in the terminal. And if you want a neat and vertical pane in vscode just drag a new terminal window next to your code and run jjui in it.
  - nchmy 8mo ago
    If there was a vscode extension that had half the power of jjui, I'd consider it. But that's not the case. jjui is just amazing.
- quleap 8mo ago
  `jjui` is the best VCS TUI I've ever used, period. I tried `lazygit` and `magit` before and was not impressed.
  - nchmy 8mo ago
    Strongly agree, and it's always getting better. The maintainer is a hero, and there's a few other regular contributors who do great work. They're always super responsive to feedback
zerr 8mo ago
Not to be confused with Visual J++ :)
- KingMob 8mo ago
  "Now, that's a name I've not heard in a long time. A long time."
  - zerr 8mo ago
    Yeah, all of the kids moved to Visual J# :)
- egeozcan 8mo ago
  At least that's somewhat relevant. Every time I hear JJ, I remember Jay-Jay Okocha: https://en.wikipedia.org/wiki/Jay-Jay_Okocha https://en.wikipedia.org/wiki/Jay-Jay_Okocha
bergheim 8mo ago
If anyone uses frontends like magit - what is the usecase for this? I feel like git is just easy-mode with magit and I don't really miss a whole lot more. I totally get this is you are using the git cli or some such. Might just be my limited imagination though of course.
- steveklabnik 8mo ago
  One obvious case where magit isn’t useful as opposed to jj is if you’re not an emacs user. jj has some additional features over just a nicer UI that I believe magit can’t do, but given that I haven’t used magit yet I am not 100% sure of how that comparison is exactly.
- rtpg 8mo ago
  rebasing, rebasing, rebasing. I used/use magit a lot, and rebasing is much nicer with magit. But you're still faced with having to be in git land. JJ there's a lot of "rebasing at the speed of thought" because you really are just moving nodes around and "do what I mean" kicks in. There's this other thing too, which is that jj I've always felt comfortable modifying changes that are not what I currently have checked out. With git it's always felt like the first step for any change management is "check out the changes into the working copy".
codethief 8mo ago
> Stay in your editor while GitHub does the rest. VisualJJ tracks pull-request status on the change tree and lets you create PRs in a couple of clicks, so moving changes from “draft” to “merged on GitHub” feels like one smooth flow. Does it support stacking PRs? EDIT: I should have looked more closely, looks like it does, though only in the Pro version: https://www.visualjj.com/docs/stacking https://www.visualjj.com/docs/stacking
meling 8mo ago
Great to see this. I played around with jj about two months ago and really enjoyed using it on the command line, but I found it difficult to understand the interaction with git and GitHub and decided to put it off until I had more time. (I don’t recall the specific issues I had…) Maybe this extension can remove some of that friction.
nailer 8mo ago
For anyone else that has absolutely no idea what this is: https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj
gcr 8mo ago
This extension snapshots the working state every 60 seconds by default. I ran out of disk space and had to turn that behavior off. YMMV. It’s a great extension otherwise though.
spartanatreyu 8mo ago
I'm not convinced by jujutsu yet. If I'm using git for version control, I'm going to use the Fork client (fork.dev) since it essentially replaces git's UI already. And in a few years if I'm in the position where we want to switch away from git, I'd probably be looking at pijul. But maybe that will change if jujutsu gets an open source non-git-based backend.
vivzkestrel 8mo ago
stupid question: why do people want to move away from git? and why is this vcs being talked about a lot these days?
- nchmy 8mo ago
  Because jj is vastly simpler and more powerful than git, while being compatible with git (so you can keep using Github etc). There's tons of articles and videos on the topic, and many other posts here on HN about it Check out jjui in particular. Makes it even easier
- direwolf20 8mo ago
  git has a terrible user experience, but you use it because everyone else is and it's powerful — much like Linux it would be good if there was a powerful VCS with a good user experience and git compatibility
- surajrmal 8mo ago
  Git makes certain workflows more difficult than they could be. Using a different tool that makes you feel more productive is generally nice.
sankar_builds 8mo ago
cool.
vrnvu 8mo ago
Ditched git for jj a year ago. Never going back. If anybody is hesitant give it a try!
antman 8mo ago
10$ per month early access? I would prefer a one off price for an offline mode
tester89 8mo ago
Doesn’t seem to properly support workspaces :’(

181 points by demail 8mo ago

It does look nice, I'll give it a go. Just wanted to say that "Git-out-of-the-way source control" is the best tiny description of JJ I've ever seen, because it's both true and the pun works perfectly. It brought me joy.

AbuAssar 8mo ago
it is worth noting that Jujutsu uses Git’s storage, networking, and ecosystem.
- SAI_Peregrinus 8mo ago
  Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.
  - capitainenemo 8mo ago
    Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues referenced in a jujutsu intro guide last year linked on HN) The same issue hit the initial efforts (that I think were the inspiration for jj) when the mercurial folks, recognising git had kinda taken over the market, experimented in making a mercurial frontend backed by the git db. Limitations like the diff format (mercurial's weave one is one the jj folks also want to add at some point) and the lack of a method for tracking phases (mercurial relies on this for clean history without throwing out commits), and lack of file move/copy tracking.
    - gcr 8mo ago
      This comment made me reconsider my attitude about git a little bit. Thank you.
- steveklabnik 8mo ago
  It uses it when you use the git backend, but not when you don’t. Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.
  - tuwtuwtuwtuw 8mo ago
    For anyone that does not work at Google, it sounds like an implementation detail that does not matter.
    - steveklabnik 8mo ago
      Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git. To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's useless. jj is still pre-1.0 software, there's a lot more work to do, and more interesting things coming down the pipeline. That matters, even if it's not relevant to every potential user just yet.
      - minraws 8mo ago
        10 years of using Git and I never knew undo was what I craved. And the ability to rebase and edit commits in a single command. Solves 90% of my problems so haven't felt like I needed any additional tooling on top of jj. But I am curious is there some edge case on jj that I missed. That you folks are working on improving tooling for? Just really curious about this new world with some better solutions to git. I liked pijul a bunch too but lack of compat with git meant I can't use it for work... Haha real sad moment right there.
        Zacharias030 8mo ago
        Not working on it (yet), but I wish the jj <-> github story was a little more ergonomic. Additionally, I am really missing support for stacked diffs, ie, easily pushing a number of commits into one PR on github each such that they all show their incremental diff. ezyang's gh stack was pretty useful, if a little bit fragile [0] and graphite.dev is also very nice, but paid software with a strong VC based motivation to become everyone's everything instead of a nice focused tool. [0] https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack I'm also not super happy with the default 3-way merge editor, but often cannot use vscode or other GUIs.

lima 8mo ago

There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk https://github.com/keanemind/jjk

KingMob 8mo ago
jjk caused a lot of problems for me when using multiple agents. It's running some sort of jj command that snap-shotted stuff and caused divergence (might have benefited from `--ignore-working-copy`). Not sure what the precise details were, but I gave up and uninstalled it after a week.
- dwattttt 8mo ago
  Multiple agents is definitely tempting fate. Concurrent modification of the same git repo by multiple entities? At that point you should use multiple repos so they can merge & resolve. EDIT: of course, if a single agent uses git to modify a repo instead of jj, jj may have trouble understanding what's happened. You could compare it to using an app that uses an sqlite db, and then also editing that db by hand.
  - gcr 8mo ago
    The OP is talking about the `jj workspace create` command, which creates a separate working copy backed by the same repository. It’s not a bad way to work with multiple agents, but you do have to learn what to do about workspace divergence. Like git, you don’t lose any history.
  - KingMob 8mo ago
    Sibling comment from gcr has the right details. This doesn't involve git use at all. Even with multiple workspaces (like git worktrees), once you use something like jjk, both the agent and jjk in the associated VS Code are operating on the same workspace, so that doesn't isolate enough. I don't think jjk uses `--ignore-working-copy` for read-only status updates, so it's snapshotting every time it checks the repo status while the agent is editing. On top of that, throw in whatever Claude does if you "rewind" a conversation that also "reverts" the code, and agents wrongly deciding to work on code outside their focus area. It's possible watchman helps (I need to look into that), but I'm so rarely using jj in VS Code (all I really want is inline blame), that it was easier to remove jjk than try to debug it all. Divergence won't hide or lose any work, but it's an annoying time-suck to straighten out.

hirako2000 8mo ago

Just me or does sit well to monetize _mostly_ off the core benefits of an open source application? Can't be easy to build a GUI on top, but I'm sure a 10% revenue to be redistributed to the hero behind jj would go a long way. Would also pay off.

throwatdem12311 8mo ago
There is nothing about neither the licensing of jj or the spirit of open source that stigmatizes this.
- hirako2000 8mo ago
  Nothing against, I agree.
Valodim 8mo ago
The hero behind jj is employed by Google afaik, so we're good.
misnome 8mo ago
10% revenue to google?
- hirako2000 8mo ago
  Touché
- surajrmal 8mo ago
  While the primary maintainer is a Google employee, the majority of commits and committers are not. It's decidedly not a Google project.
  - 3eb7988a1663 8mo ago
    I mean the Google CLA kind of says otherwise.

olup 8mo ago

I wanted the same extension but more steerable and open source, so I built open jj recently https://github.com/olup/open-jj https://github.com/olup/open-jj

IshKebab 8mo ago
You gotta put screenshots in the readme!

Okkef 8mo ago

I worked with JJ for half a year, and it was great. However, I've since decided to go back to GIT because of compatibility with existing workflows and AI tools. Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fall back to git too often.

Yeroc 8mo ago
Seeing similar comments across different articles and technologies and it makes me wonder how much AI is going to hold back the adoption of new technologies going forward.
- hippo22 8mo ago
  I agree it will hold back new technologies, but, at the same time, I'm not sure what the value add of new technologies will be going forward. Often, as is the case with git vs. jj, the value add of a new technology is mostly ergonomic. As AI becomes more ingrained in the development flow, engineers won't engage with the underlying tech directly, and so ergonomic benefits will be diminished. New technologies that emerge will need to provide benefits to AI-agents, not to engineers. Should such a technology emerge, agent developers will likely adopt it. For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.
  - surajrmal 8mo ago
    Even if you're not authoring changes as much, change management is likely still to be a very useful activity for a long while. Also note that not everyone is using AI today, and many that do only use it as glorified auto complete. It will take many more years for it's adoption to put us in a situation like your describing, why halt progress in the meantime? My personal productivity increased greatly by switching to jj, perhaps more than adding Gemini CLI to my workflow. I can more confidently work on several changes in parallel while waiting on things like code review. This was possible before but rebasing it and dealing with merge conflicts tended to limit me from doing it beyond a handful of commits. Now I can have 20+ outstanding commits (largely with no interdependencies) and not feel like I'm paying much management overhead while doing so. I can also get them reviewed in parallel more easily.

SkoogyDan 8mo ago

There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui https://github.com/idursun/jjui

surajrmal 8mo ago
I love jjui, but I feel like it's also the reason I still use him over vscode. If you already use vscode, doesn't using a vscode extension make more sense?
- SkoogyDan 8mo ago
  Of course there are some people that will want a gui not matter what. Then an extension or separate program is the only thing you can do. But i think it is really nice to have the same tool available everywhere, also in the terminal. And if you want a neat and vertical pane in vscode just drag a new terminal window next to your code and run jjui in it.
- nchmy 8mo ago
  If there was a vscode extension that had half the power of jjui, I'd consider it. But that's not the case. jjui is just amazing.
quleap 8mo ago
`jjui` is the best VCS TUI I've ever used, period. I tried `lazygit` and `magit` before and was not impressed.
- nchmy 8mo ago
  Strongly agree, and it's always getting better. The maintainer is a hero, and there's a few other regular contributors who do great work. They're always super responsive to feedback

zerr 8mo ago

Not to be confused with Visual J++ :)

KingMob 8mo ago
"Now, that's a name I've not heard in a long time. A long time."
- zerr 8mo ago
  Yeah, all of the kids moved to Visual J# :)
egeozcan 8mo ago
At least that's somewhat relevant. Every time I hear JJ, I remember Jay-Jay Okocha: https://en.wikipedia.org/wiki/Jay-Jay_Okocha https://en.wikipedia.org/wiki/Jay-Jay_Okocha

bergheim 8mo ago

If anyone uses frontends like magit - what is the usecase for this? I feel like git is just easy-mode with magit and I don't really miss a whole lot more. I totally get this is you are using the git cli or some such. Might just be my limited imagination though of course.

steveklabnik 8mo ago
One obvious case where magit isn’t useful as opposed to jj is if you’re not an emacs user. jj has some additional features over just a nicer UI that I believe magit can’t do, but given that I haven’t used magit yet I am not 100% sure of how that comparison is exactly.
rtpg 8mo ago
rebasing, rebasing, rebasing. I used/use magit a lot, and rebasing is much nicer with magit. But you're still faced with having to be in git land. JJ there's a lot of "rebasing at the speed of thought" because you really are just moving nodes around and "do what I mean" kicks in. There's this other thing too, which is that jj I've always felt comfortable modifying changes that are not what I currently have checked out. With git it's always felt like the first step for any change management is "check out the changes into the working copy".

codethief 8mo ago

> Stay in your editor while GitHub does the rest. VisualJJ tracks pull-request status on the change tree and lets you create PRs in a couple of clicks, so moving changes from “draft” to “merged on GitHub” feels like one smooth flow. Does it support stacking PRs? EDIT: I should have looked more closely, looks like it does, though only in the Pro version: https://www.visualjj.com/docs/stacking https://www.visualjj.com/docs/stacking

meling 8mo ago

Great to see this. I played around with jj about two months ago and really enjoyed using it on the command line, but I found it difficult to understand the interaction with git and GitHub and decided to put it off until I had more time. (I don’t recall the specific issues I had…) Maybe this extension can remove some of that friction.

nailer 8mo ago

For anyone else that has absolutely no idea what this is: https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj

gcr 8mo ago

This extension snapshots the working state every 60 seconds by default. I ran out of disk space and had to turn that behavior off. YMMV. It’s a great extension otherwise though.

spartanatreyu 8mo ago

I'm not convinced by jujutsu yet. If I'm using git for version control, I'm going to use the Fork client (fork.dev) since it essentially replaces git's UI already. And in a few years if I'm in the position where we want to switch away from git, I'd probably be looking at pijul. But maybe that will change if jujutsu gets an open source non-git-based backend.

vivzkestrel 8mo ago

stupid question: why do people want to move away from git? and why is this vcs being talked about a lot these days?

nchmy 8mo ago
Because jj is vastly simpler and more powerful than git, while being compatible with git (so you can keep using Github etc). There's tons of articles and videos on the topic, and many other posts here on HN about it Check out jjui in particular. Makes it even easier
direwolf20 8mo ago
git has a terrible user experience, but you use it because everyone else is and it's powerful — much like Linux it would be good if there was a powerful VCS with a good user experience and git compatibility
surajrmal 8mo ago
Git makes certain workflows more difficult than they could be. Using a different tool that makes you feel more productive is generally nice.

sankar_builds 8mo ago

cool.

vrnvu 8mo ago

Ditched git for jj a year ago. Never going back. If anybody is hesitant give it a try!

antman 8mo ago

10$ per month early access? I would prefer a one off price for an offline mode

tester89 8mo ago

Doesn’t seem to properly support workspaces :’(