Remix.run Logo
tuwtuwtuwtuw 8 hours ago

For anyone that does not work at Google, it sounds like an implementation detail that does not matter.

steveklabnik 8 hours ago | parent [-]

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 2 hours ago | parent [-]

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 an hour ago | parent [-]

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

I'm also not super happy with the default 3-way merge editor, but often cannot use vscode or other GUIs.