Collaboration with lazyjj?

[Malix-Labs]

Maybe it would be a nice idea to collaborate with https://github.com/Cretezy/lazyjj ?

By that, I mean upstreaming the repository, and integrating @Cretezy in the https://github.com/jj-vcs organization?

I imagine it would enable more seamless work

[shanesveller]

There are a variety of third-party applications like lazyjj, listed on the official web site here and on the GitHub repo wiki here.

There are presumably other such projects that are still being worked on and haven't yet been published or documented on one of those pages.

I'm not intending to speak for the maintainers here but I suspect they are not ready to "bless" any of these projects as more official than they are today, and you might also find that the authors of those projects actively prefer being independent from jj's maintainer and governance practices for whatever reason. They may not want to make the necessary changes to join upstream even if they were offered such a choice, may not feel ready to do so, prefer their autonomy, etc. and no one but the creators can make those kinds of decisions.

In terms of this repo's maintainer permissions and responsibilities specifically, that would be the purview of the formal governance structure which was ratified here. The initial election process for formal maintainer roles was held here and concluded here. If this user wishes to be involved at that level, perhaps they can be nominated or self-nominate whenever the next maintainer election occurs.

[thoughtpolice]

I personally (and not speaking for the entire maintainer group) do not think we're ready to accept a blessed terminal UI right now or the (relative) near future. There are currently multiple various TUIs floating around following people's various tech and UX choices, and I think that's basically fine for the time being. The main thing for us is it will add a lot of maintenance burden and new user demands. Not unfathomable or impractical levels of difficulty at all, but I don't see it happening in the immediate future because we have a lot to do.

We also have a long list of "internal" things we want to do as well besides the UX, but several of them would definitely be relevant to downstream consumers like terminal UIs. For example, #3219 would make it significantly more robust to rely on jj without requiring either Rust code or having to rely on the exact structure of the command line, and is probably a requirement to open up jj to places like IDE integration (JetBrains, VS Code, etc.) I think those are better priorities for us in the near future than picking a downstream TUI and running with it (again I'm not speaking for everyone here, this is just me.)

That said, we aren't opposed to having UIs upstream in general; for example, we've all talked about adding a jj web command similar to Sapling's "interactive" smartlog web UI, which is excellent — and if you ask me, maybe of even greater value than a blessed terminal UX, I would personally use jj web all the time if we had it. We have also talked about a jj reorder command which would have a very small terminal UI for reordering commits in a selected tree which would be far smaller in scope, etc.

A big problem for us that I've thought about in the past is that, before we do any of this we need to devise a robust testing strategy for all of this stuff. We rely extensively on our tests for our existing command UI, and they are — in my opinion — a huge differentiator, and a major contributor to how high quality jj is in general. So, at the very minimum I'd rather not bless something unless we have a long-term plan to test it. That means we'll need to spend time looking at the options available to us, evaluating them, etc. Again, not impossible, but it's work I don't think we want to commit to right now. (At the moment it seems most of the testing for these kinds of things is "Compile it and run it and maybe see what's screwed up or not" which isn't ideal...)

Finally, I will also note that the criteria for joining the maintainer group, while not herculean, does reasonably require the people in question to participate in upstream a lot beforehand and contribute patches, review, design input etc. We expect maintainers to be "in it to win it" and here for the long term. Many people writing these UIs are relatively small upstream participants, and I think that's actually good in a way because it means they aren't subjected to our tyrannical code review workflows or timelines or processes. On top of that, our users today are typically very eagle-eyed and, while not pushy or in any way bad — I absolutely adore our userbase in general — they have quite high standards to meet. This is not a slight against Cretezy or any of the other developers of JJ terminal UIs; to join upstream would actually be asking quite a lot of them, is my point.

Putting my "I've been doing this for 20 years"-hat on (good god...) I value sustainability and health of the project over just trying to make things seamless or meet every demand immediately. And I think we've been threading that needle very well. The time just isn't quite right yet. I hope this makes sense.

[PhilipMetzger]

Also see the jj web issue here #2765

[Cretezy]

I believe integrating tools like lazyjj into jj is premature at this time, for several reasons.

First, this space is rapidly evolving, with new tools emerging frequently. While lazyjj was likely the first TUI implementation, we now have at least three or four alternatives. Maintaining a diverse ecosystem allows for parallel development and cross-learning among these projects.

Second, integrating one tool would inherently favor it over others. While this might be acceptable if a clear leader emerged, the landscape is currently too fragmented.

I propose revisiting integration if a tool gains widespread adoption and community consensus. Personally, I would be open to transferring lazyjj's ownership to the jj org at that point.

Separately, I strongly believe we should develop a higher-level jj API (as outlined in the roadmap). The initial POC of lazyjj was using jj-api directly, but I quickly realized I would need to reimplement most of jj-cli. The approach I went with was to call the jj binary directly and parse the results, which is not ideal. Having a better high-level API (either in Rust or RPC) would usher in a new wave of tools that aren't possible (or extremely difficult) today.