The part I really liked is that the change ID is pre-defined. This makes it easy to reference it in the code that is about to be "committed"--something that git can't do because the commit's ID is the same as the content hash.
Other than that, using a different versioning system than git isn't really helpful for me personally, when the entire world uses git. Doesn't matter if Jujutsu even would be objectively better in all points.
Well, jj is actually very nice in this regard, because:
1. it works on top of git — you keep using all the same infrastructure (GitHub, etc.)
2. in your local repositories you still have access to git-tools, as jj maintains git and its own states in sync.
After all of these months with jj I still find myself using GitUp when I need to review a long chain of commits or do some quick repo-archeology.
And, from time to time, I even use Idea's merge tools because their "magic wand" saves a lot of time.
The part I really liked is that the change ID is pre-defined. This makes it easy to reference it in the code that is about to be "committed"--something that git can't do because the commit's ID is the same as the content hash.
Other than that, using a different versioning system than git isn't really helpful for me personally, when the entire world uses git. Doesn't matter if Jujutsu even would be objectively better in all points.
Well, jj is actually very nice in this regard, because:
1. it works on top of git — you keep using all the same infrastructure (GitHub, etc.) 2. in your local repositories you still have access to git-tools, as jj maintains git and its own states in sync.
After all of these months with jj I still find myself using GitUp when I need to review a long chain of commits or do some quick repo-archeology. And, from time to time, I even use Idea's merge tools because their "magic wand" saves a lot of time.
I mentioned this in the first part of series