You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This discussion is about #21538. I opened a new discussion to avoid spamming the issue.
I would like to work on a better jj integration over the next couple month and would like to put more structure into the workstream. It would be great if we can work more closely with the Zed team on this!
Project Milestones
I would like to split the workstream into the two following milestones:
git blame - inline blame still works and is very helpful
git diff - The diff view and restoring changes
Colocating the git repository comes with a performance hit, so this is not ideal. Before we add a jj UI, I would like to add support for jj diff and jj file annotate (the jj equivalents of git blame and git diff). This requires some work upstream in the jj, but I am happy to take on that challenge.
It's already a big win if Zed users do not need to colocate the repos anymore, especially for very large repos.
Building a jj UI
@maxdeviant added a picker for jj bookmark list in #30883, but it's behind a feature flag jj-ui and I don't know if there has been any development since.
There are probably many different opinions on the UI, so I would focus on implementing blame and diff now, but it would be great if we can already talk about how a nice UI should look like in the future. I am not a designer/frontend dev, so maybe someone here finds time to make some sketches that we can iterate on?
Most jj TUIs call the jj CLI and parse the output instead of using the jj-lib crate (even the ones written in Rust). This is because the jj-lib is not that good atm. However, I think we should take the ambitious approach and consume jj as a library and we shouldn't use the CLI and make the necessary upstream contributions - other IDEs/app authors will benefit from this as well.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
This discussion is about #21538. I opened a new discussion to avoid spamming the issue.
I would like to work on a better jj integration over the next couple month and would like to put more structure into the workstream. It would be great if we can work more closely with the Zed team on this!
Project Milestones
I would like to split the workstream into the two following milestones:
Removing the need to co-locate Jujutsu/Git repos
Currently, most Zed + jj users colocate the Jujutsu/Git repos for two reasons:
git blame- inline blame still works and is very helpfulgit diff- The diff view and restoring changesColocating the git repository comes with a performance hit, so this is not ideal. Before we add a jj UI, I would like to add support for
jj diffandjj file annotate(the jj equivalents ofgit blameandgit diff). This requires some work upstream in the jj, but I am happy to take on that challenge.It's already a big win if Zed users do not need to colocate the repos anymore, especially for very large repos.
Building a jj UI
@maxdeviant added a picker for
jj bookmark listin #30883, but it's behind a feature flagjj-uiand I don't know if there has been any development since.There are probably many different opinions on the UI, so I would focus on implementing
blameanddiffnow, but it would be great if we can already talk about how a nice UI should look like in the future. I am not a designer/frontend dev, so maybe someone here finds time to make some sketches that we can iterate on?Using jj as a CLI or as a lib
We have to options to communicate with jj:
Most jj TUIs call the jj CLI and parse the output instead of using the jj-lib crate (even the ones written in Rust). This is because the jj-lib is not that good atm. However, I think we should take the ambitious approach and consume jj as a library and we shouldn't use the CLI and make the necessary upstream contributions - other IDEs/app authors will benefit from this as well.
Beta Was this translation helpful? Give feedback.
All reactions