Would've been nice to show how jj solves the issues presented in the article. I assume it's obvious for jj users but they're probably also not the target audience.
You're not alone by any means. One of the most important things about tools is that they're part of dynamic systems. What a tool lets you do feeds back into what you believe you can do, which in turn feeds into your belief about the tool, which shapes how the tool evolves.
When a tool shakes up the status quo, your beliefs about what you can do shift, as do your expectations.
OK but then maybe these kinds of articles should explain why I need those things they claim I do. Because when I have my beliefs it's hard to re-evaluate them by just seeing 'oh wow jj can do this cool new thing'.
I'm not going to comment on the everything in the article (I'm not sure that's what you're looking for, anyway). But I can tell you why I use, and have spent a significant amount of my career, working on stacked diffs/PRs: it is to let developers communicate with the machine and with each other through smaller, atomic, bisectable units of code. I genuinely believe it is a better way to build software in teams, and I'm not alone in that belief.
I understand it's difficult to come up with compelling justifications that force people to say something is genuinely innovative. Sometimes the new tool just doesn't have one!
updateRefs was indirectly inspired by a lot of the work we did at Meta to enable stacked PRs. But also, Git's support for this workflow is overall quite bad compared to Jujutsu. There are several things that come together to make this a reality.
I understand it's difficult to come up with compelling justifications that force people to say something is genuinely innovative.
I think, as a former professional in this specific niche, that Jujutsu is genuinely innovative in many ways. I'm not going to "force" you to agree, though. That would be quite silly. All I can do is say what I believe.
Your working copy commit can have multiple parents (ie act like a merge commit) with 'jj new A B', so your working copy will have the changes from both parents, and you can build off the merge or amend into either commit, etc.
hmpc | 4 hours ago
Would've been nice to show how jj solves the issues presented in the article. I assume it's obvious for jj users but they're probably also not the target audience.
yawaramin | 3 hours ago
I've never needed the things that the article claims git can't do as justification why git is not fine. Is it just me?
sunshowers | 3 hours ago
You're not alone by any means. One of the most important things about tools is that they're part of dynamic systems. What a tool lets you do feeds back into what you believe you can do, which in turn feeds into your belief about the tool, which shapes how the tool evolves.
When a tool shakes up the status quo, your beliefs about what you can do shift, as do your expectations.
yawaramin | 2 hours ago
OK but then maybe these kinds of articles should explain why I need those things they claim I do. Because when I have my beliefs it's hard to re-evaluate them by just seeing 'oh wow jj can do this cool new thing'.
sunshowers | 2 hours ago
I'm not going to comment on the everything in the article (I'm not sure that's what you're looking for, anyway). But I can tell you why I use, and have spent a significant amount of my career, working on stacked diffs/PRs: it is to let developers communicate with the machine and with each other through smaller, atomic, bisectable units of code. I genuinely believe it is a better way to build software in teams, and I'm not alone in that belief.
yawaramin | 2 hours ago
But...git can do stacked PRs too. It even added support with
updateRefs: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refsI understand it's difficult to come up with compelling justifications that force people to say something is genuinely innovative. Sometimes the new tool just doesn't have one!
sunshowers | an hour ago
updateRefs was indirectly inspired by a lot of the work we did at Meta to enable stacked PRs. But also, Git's support for this workflow is overall quite bad compared to Jujutsu. There are several things that come together to make this a reality.
My testimonial at https://docs.jj-vcs.dev/latest/testimonials/ (first one) covers some of the specifics.
I think, as a former professional in this specific niche, that Jujutsu is genuinely innovative in many ways. I'm not going to "force" you to agree, though. That would be quite silly. All I can do is say what I believe.
radio | 4 hours ago
Sounds interesting but the diagrams make me dizzy.
LenFalken | an hour ago
How does jj do this? https://www.billjings.com/posts/title/git-is-not-fine/RealityEx23.png
willhbr | an hour ago
Your working copy commit can have multiple parents (ie act like a merge commit) with 'jj new A B', so your working copy will have the changes from both parents, and you can build off the merge or amend into either commit, etc.