I’m the author, so maybe you’re not asking me, but I’ve used it for the project itself for over a year, as well as for various pull requests for other GitHub projects. I doubt anyone else has used it for anything serious, but I’d be very happy to hear if anyone has.
Removal of Mercurial-style “changeset evolution”; if you modify a commit which is the ancestor of another commit, it just magically rebases (and stores any conflicts in the descendant commit, as appropriate).
So if I understand correctly, this is the only tool based on git (afaik) that represents conflict explicitly and externally, I don’t know if you get commutative patches like in pijul but at least you can keep merging while you are in a conflict state and you can probably work with the conflict more fluidly.
No, it’s not patch-based in the way Pijul is. You can still reorder commits and end up with the same end state (see this demo, linked from the README) in most cases, but it’s not guaranteed.
For example, let’s say you have this history:
C = A
|
B = A^-1
|
A
|
X
So B undoes the changes in A, and then C redoes the changes again. If you now reorder them, so C comes right after A, then it makes the same changes as A, so the commit becomes empty (just like it would with regular Git or Mercurial). So if you then move B on top, the end result will be that there are no changes between X and the top of the stack. My understanding is that order doesn’t matter in Pijul, so there’s no such thing as reordering patches, and the end result of the three patches above would be as it is before the reordering.
The case above is of course pretty unusual, and rarely matters in practice, but it’s a difference between (my understanding of) Pijul’s model and Jujutsu’s Git-like model nonetheless.
I do talk to Sturdy folks and I don’t think they are solving the same problems that JJ solved.
I think the closest companies i have seen any success around this space that is NOT a big players are: SourceHut, Heptapod. Especially the way Heptapod took the Gitlab FOSS and reimplemented the Gitaly GRPC layer was particularly genius.
Same could be done with JJ, enabling a self-hosted Gitlab instance to run both Git and JJ in parallel. Thats how you get BIG customers with self-hosted monorepo to try out the product.
I don’t wish to nitpick, I’m glad you mentioned it’s OSS because I will now consider your product.
That said, it seems to be better described as open core, since “This repository contains both OSS-licensed and non-OSS-licensed files”, because you have an “Enterprise” version. I’m having difficulty telling exactly which features are available in the core OSS product vs. the Enterprise version, the first page of the docs mentions the OSS version is missing “OAuth, incremental migrations to Sturdy, etc” but I don’t see an exhaustive list anywhere.
We use Go build tags, and in this setup, one can’t accidentally build/link non-oss code if they don’t explicitly pass -tags enterprise. Perhaps the readme can make it more clear, thanks for this feedback!
OOC, in Sturdy is there any support for commit messages? How does annotate work as an operation? Assuming you don’t have commit messages, have you found that limiting for when you have to do code archaeology?
It will produce a commit message with the text provided in the description box, so in that sense, you can do code archeology. What we call workspaces are like live pull requests, and they are ready, they produce one commit - a big emphasis is keeping the units of work small.
There is a mechanism for taking one or multiple hunks and ‘forking’ out in a new workspace with just those changes. Doing proper stacking is of huge interest to me (I used to do stacked PRs at a previous job). At the moment we are still thinking of what a good UI/UX would look like for it.
Since this is git-compatible, anyone using this to work on a git repository shared with git users?
I’m the author, so maybe you’re not asking me, but I’ve used it for the project itself for over a year, as well as for various pull requests for other GitHub projects. I doubt anyone else has used it for anything serious, but I’d be very happy to hear if anyone has.
Some interesting things which have changed since the last time this was posted:
So if I understand correctly, this is the only tool based on git (afaik) that represents conflict explicitly and externally, I don’t know if you get commutative patches like in pijul but at least you can keep merging while you are in a conflict state and you can probably work with the conflict more fluidly.
I’ll have to try this I guess.
No, it’s not patch-based in the way Pijul is. You can still reorder commits and end up with the same end state (see this demo, linked from the README) in most cases, but it’s not guaranteed.
For example, let’s say you have this history:
So B undoes the changes in A, and then C redoes the changes again. If you now reorder them, so C comes right after A, then it makes the same changes as A, so the commit becomes empty (just like it would with regular Git or Mercurial). So if you then move B on top, the end result will be that there are no changes between X and the top of the stack. My understanding is that order doesn’t matter in Pijul, so there’s no such thing as reordering patches, and the end result of the three patches above would be as it is before the reordering.
The case above is of course pretty unusual, and rarely matters in practice, but it’s a difference between (my understanding of) Pijul’s model and Jujutsu’s Git-like model nonetheless.
I have very high hope for this to get a startup behind it
I think the author doesn’t plan to quit their day job, but hopefully we’ll see some of the ideas enter mainstream VCSes
The closest startup-backed thing might be https://getsturdy.com/.
I do talk to Sturdy folks and I don’t think they are solving the same problems that JJ solved.
I think the closest companies i have seen any success around this space that is NOT a big players are: SourceHut, Heptapod. Especially the way Heptapod took the Gitlab FOSS and reimplemented the Gitaly GRPC layer was particularly genius.
Same could be done with JJ, enabling a self-hosted Gitlab instance to run both Git and JJ in parallel. Thats how you get BIG customers with self-hosted monorepo to try out the product.
Founder of Sturdy here. I’d say our focus is a bit different. I have been thinking a lot about coding workflows at work and how feedback is exchanged.
I’m very interested in the idea of exchanging feedback early, just like pair-programming, but being able to do so asynchronously, like PR reviews.
By the way, I wanted to mention, Sturdy is also open-source - https://github.com/sturdy-dev/sturdy
I don’t wish to nitpick, I’m glad you mentioned it’s OSS because I will now consider your product.
That said, it seems to be better described as open core, since “This repository contains both OSS-licensed and non-OSS-licensed files”, because you have an “Enterprise” version. I’m having difficulty telling exactly which features are available in the core OSS product vs. the Enterprise version, the first page of the docs mentions the OSS version is missing “OAuth, incremental migrations to Sturdy, etc” but I don’t see an exhaustive list anywhere.
The structure is - files that are under any directory named enterprise are enterprise, for example, this package https://github.com/sturdy-dev/sturdy/tree/main/api/pkg/queue/enterprise
We use Go build tags, and in this setup, one can’t accidentally build/link non-oss code if they don’t explicitly pass
-tags enterprise. Perhaps the readme can make it more clear, thanks for this feedback!OOC, in Sturdy is there any support for commit messages? How does annotate work as an operation? Assuming you don’t have commit messages, have you found that limiting for when you have to do code archaeology?
It will produce a commit message with the text provided in the description box, so in that sense, you can do code archeology. What we call workspaces are like live pull requests, and they are ready, they produce one commit - a big emphasis is keeping the units of work small.
Interesting. Is there a way to stack workspaces at all? I often find I end up writing my changes in reverse of the order they need to land in a repo.
There is a mechanism for taking one or multiple hunks and ‘forking’ out in a new workspace with just those changes. Doing proper stacking is of huge interest to me (I used to do stacked PRs at a previous job). At the moment we are still thinking of what a good UI/UX would look like for it.
Those rebase scenarios look pretty nice. Git is always a bit scary when doing that.