jjui: a text user interface (TUI) for the Jujutsu version control system
25 points by fanf
25 points by fanf
Is anyone keeping a list of projects that use jujutsu_lib? I only seen UIs (including jjui) that shell out to jj
https://github.com/gulbanana/gg and (non-open-source) https://www.visualjj.com/ link to jj_lib and (I believe) jj_cli as well. There are upsides and downsides to that; both the CLI and jj_lib often have breaking changes. The repo format has breaking changes less often, so old versions of gg often keep mostly working for a while.
Oh wow, visualjj looks interesting. It even has Sapling’s multi-way split GUI!
The author mentioned on jj’s forum that it’s based on Sapling’s ISL code (probably heavily modified by now).
That makes sense, it’s a great starting point. ISL/Sapling are GPL tho so either visualjj’s not based on ISL or it has to be open source tho, right?
Some parts of Sapling have a more permissive license, e.g. Apache. For example, jj is using their graph drawing code, which they helpfully re-licensed as Apache for us (since that library was fully Meta-owned-and-copyrighted). I’m not sure about the VS Code and ISL-related code specifically.
Update: I think this the ISL code is MIT-licensed, but I am very much not a lawyer/expert/etc. The relevant code seems to be covered by https://github.com/facebook/sapling/blob/main/addons/LICENSE. See also https://github.com/facebook/sapling/tree/main?tab=readme-ov-file#license.
Older text (before I couldn’t resist speculating more 😅): Beyond that, I seem to have already speculated too much. I vaguely remember that VisualJJ’s author may have said something about using Sapling’s VS Code extension code a while ago, and that’s about all I know for sure. When you mentioned that the split GUI is related to Sapling’s, I made an assumption that VisualJJ uses the same code, but I actually have no idea. If you like, you can ask the author of VisualJJ directly, either via email on the VisualJJ website or via the jj Discord.
Sorry to nerd snipe you: I totally don’t need to know, it’s fine 😅.
Although I do love hearing how great the Sapling team continues to be. Such great folks.
If you wouldn’t mind I would take a link to the jj forum. I couldn’t find it via googling. Or is it just the discord?
Yes, I meant the Discord; the link is in jj’s README. Or you can use #jujutsu on Libera for IRC (which is bridged to the Discord).
Hot take: I think that the multiplication of overlay UIs on top of an existing program is not a good thing. This fragments the userbase, and reduces incentives for the upstream project to invest in UI improvements (“this feature is already provided in separate tool …”). I wish that authors of such UIs would invest time in improving the UI of the original program; this may result in slower progress due to the necessity to coordinate with others and build consensus, but the resulting improvements would reach a much wider userbase and let different authors build on each other.
In the git words there are many different UIs on top of git because the upstream UI is rather bad. I would like to live in a world where the base tool has good UI. jj is making credible efforts at improving its UI, why not propose integrating a TUI mode there?
(Obviously this comes with technological constraints, for example this one program appears to be in Go whereas upstream would probably ask for Rust. I don’t see this as being a significant issue, at least in the world of TUIs.)
I think that most jj developers consider a tui or gui to be out of scope for the main project. I’d certainly be happy to contribute gg as an implementation of jj gui if that’s not the case!
I don’t know what jj developers/maintainer think. Has this question been asked upstream before, and clearly been answered in the way that you suggest? It is far from obvious to me. For example jj comes with a builtin pager and with a builtin TUI tool for diff edition (similar to git add -p).
I discussed gg with other jj developers in the community discord while building it. The general consensus at the time was that they wanted to focus on a high-quality command-line interface, and possibly a jj web that would be relatively easy to port and distribute. The people at Google who do some funded jj work are also interested in creating a daemon with an RPC interface to support alternative clients - personally I’m not sure this will go anywhere, but it does address the use case of clients that aren’t written in Rust.
It is fun to see a project that is made by one of the co-workers I met during my internship 6 years ago randomly show up in Lobsters’ frontpage. And also it looks pretty cool!