4 ms·

Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discu

by rapnie 3y ago

Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discussed a number of times on HN before. [0] https://github.com/martinvonz/jj https://github.com/martinvonz/jj [1] 4 montsh ago, 261 comments https://news.ycombinator.com/item?id=36952796 https://news.ycombinator.com/item?id=36952796 [2] 2 years ago, 228 comments https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662

swah 3y ago
Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.
- bryanlarsen 3y ago
  Rust is a fabulous language for refactoring. Strong types and complete matching make it almost completely impossible to miss a spot when making a change
- dontlaugh 3y ago
  I feel the opposite way. Even though Python is the language I’ve used most, I wouldn’t want to use it for something with a lot of uncertainty and that will suffer many changes. Type systems make it so much easier to change things early on without breaking everything. I’d probably pick F# or similar.
  - gsuuon 3y ago
    There actually is a similar project in F#: https://github.com/ScottArbeit/Grace https://github.com/ScottArbeit/Grace
- Smaug123 3y ago
  Python certainly lets you change things quickly, because it does not let you automatically enforce any invariants; this is why it lets you get into such extraordinary inconsistent states so easily! I personally could never imagine trying to make a jigsaw out of jelly because "it's v1 and I'll make v2 properly".
- martinvonz 3y ago
  The current DVCS solution at Google is based on Mercurial, which is written in Python. Having worked on that for many years, I didn't want to write jj in Python. We've had problems with the performance of the current solution. Also, as others have said in sibling replies, refactoring Python is not fun due to lack of static types (I know it's gotten better).
- aseipp 3y ago
  There are other advantages aside from the static types debate in the other replies. The need for efficient version control systems is a constant and ongoing battle; you can pick the right data structures (for example, Git's issues with large files are more of a data structure problem than one of raw efficiency) but at the end of the day Python will often be behind on raw performance. Rust will hopefully let us embed the Jujutsu libraries inside other languages, something you can only achieve today in Git with something like libgit2. Finally, a lot of the infrastructure we get to use, like nextest and cargo-insta are simply fantastic even if I have my qualms about Cargo. Most of the developers (some of them being former Mercurial and Git developers) including me generally seem to like it. Based on my own experience, I think it's a pretty excellent choice, but I'd be a bit biased as a die-hard Haskell/C programmer for something fast with types.
- mhh__ 3y ago
  I'm not particularly productive in python. The code gets shat out faster but it's a comparatively weak language for capital-P Programming — lack of types means repeating and checking yourself a lot.
johnwheeler 3y ago
I tried this, and I loved it. It works very well with my workflow. Perhaps the author can explain - when you clone the repo with jj git clone It pulls down a branch that is auto generated like pull-(hash) I can’t understand how not to get that corrupted so when I do a jj log, I get very weird branches or heads or I’m not sure what. Another way to say it is that everything works great until I have to pull down the repo from another machine - then the branch history is not what I expect. And I just couldn’t make sense of it or get it to square with what I expected. I actually created a custom GPT and fed it the jj code and documentation to try and get it to explain it to me to no avail. Jj is so good, I’m willing to give up IDE integration with git if I could just crack this nut.
- martinvonz 3y ago
  I can't tell what the problem is based on that description. Feel free to file a bug report, or start a GitHub discussion, or ask on Discord.
- aseipp 3y ago
  Just echoing Martin, but: if you can show the repository that is causing this, or at least a screenshot (or something) showing what you're seeing and post it on GitHub, one of us should at least be able to help figure out what's going on.
  - johnwheeler 3y ago
    I have created a discussion. Thank you both https://github.com/martinvonz/jj/discussions/2691 https://github.com/martinvonz/jj/discussions/2691

by rapnie 3y ago

swah 3y ago

Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.

bryanlarsen 3y ago
Rust is a fabulous language for refactoring. Strong types and complete matching make it almost completely impossible to miss a spot when making a change
dontlaugh 3y ago
I feel the opposite way. Even though Python is the language I’ve used most, I wouldn’t want to use it for something with a lot of uncertainty and that will suffer many changes. Type systems make it so much easier to change things early on without breaking everything. I’d probably pick F# or similar.
- gsuuon 3y ago
  There actually is a similar project in F#: https://github.com/ScottArbeit/Grace https://github.com/ScottArbeit/Grace
Smaug123 3y ago
Python certainly lets you change things quickly, because it does not let you automatically enforce any invariants; this is why it lets you get into such extraordinary inconsistent states so easily! I personally could never imagine trying to make a jigsaw out of jelly because "it's v1 and I'll make v2 properly".
martinvonz 3y ago
The current DVCS solution at Google is based on Mercurial, which is written in Python. Having worked on that for many years, I didn't want to write jj in Python. We've had problems with the performance of the current solution. Also, as others have said in sibling replies, refactoring Python is not fun due to lack of static types (I know it's gotten better).
aseipp 3y ago
There are other advantages aside from the static types debate in the other replies. The need for efficient version control systems is a constant and ongoing battle; you can pick the right data structures (for example, Git's issues with large files are more of a data structure problem than one of raw efficiency) but at the end of the day Python will often be behind on raw performance. Rust will hopefully let us embed the Jujutsu libraries inside other languages, something you can only achieve today in Git with something like libgit2. Finally, a lot of the infrastructure we get to use, like nextest and cargo-insta are simply fantastic even if I have my qualms about Cargo. Most of the developers (some of them being former Mercurial and Git developers) including me generally seem to like it. Based on my own experience, I think it's a pretty excellent choice, but I'd be a bit biased as a die-hard Haskell/C programmer for something fast with types.
mhh__ 3y ago
I'm not particularly productive in python. The code gets shat out faster but it's a comparatively weak language for capital-P Programming — lack of types means repeating and checking yourself a lot.

johnwheeler 3y ago

I tried this, and I loved it. It works very well with my workflow. Perhaps the author can explain - when you clone the repo with jj git clone It pulls down a branch that is auto generated like pull-(hash) I can’t understand how not to get that corrupted so when I do a jj log, I get very weird branches or heads or I’m not sure what. Another way to say it is that everything works great until I have to pull down the repo from another machine - then the branch history is not what I expect. And I just couldn’t make sense of it or get it to square with what I expected. I actually created a custom GPT and fed it the jj code and documentation to try and get it to explain it to me to no avail. Jj is so good, I’m willing to give up IDE integration with git if I could just crack this nut.

martinvonz 3y ago
I can't tell what the problem is based on that description. Feel free to file a bug report, or start a GitHub discussion, or ask on Discord.
aseipp 3y ago
Just echoing Martin, but: if you can show the repository that is causing this, or at least a screenshot (or something) showing what you're seeing and post it on GitHub, one of us should at least be able to help figure out what's going on.
- johnwheeler 3y ago
  I have created a discussion. Thank you both https://github.com/martinvonz/jj/discussions/2691 https://github.com/martinvonz/jj/discussions/2691