| |
| ▲ | steveklabnik 12 hours ago | parent | next [-] | | 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 8 hours ago | parent [-] | | 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. |
|
|
|
| |
| ▲ | SAI_Peregrinus 13 hours ago | parent | prev [-] | | Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain. | | |
| ▲ | capitainenemo 6 hours ago | parent [-] | | 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 4 hours ago | parent [-] | | This comment made me reconsider my attitude about git a little bit. Thank you. |
|
|
|
