nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqqmshcslmwan3erj3ulczepe8q8a8xdyfkndnk8fudgtg8ccwg6zqfcr0xq (nprofile…r0xq) The thing that is helping is basically that Jujutsu provides a local rebase workflow that is more reliable. One way to think about Jujutsu is that whereas Git has one unnamed staging area, Jujutsu has unlimited staging areas that can be stacked on each other in a DAG. Of course, these "staging areas" are just the mutable (i.e. non-pushed) commits in your working copy.
What makes this so nice is that I can reliably edit one of these changes and all the dependent changes get automatically rebased. This is theoretically possible in Git, and I'm fairly good at it, but for some reason in Git it always leads to lots of suffering and cascading failures. One important difference from Git, however, is that the even though the changes have a different commit ID, they keep a separate identity (the "change id") across all edits and rebases.
Anyway, when working on my forest, I sometimes have three or four changes going on at a time. Maybe I'm fixing a certain class of typo across the whole forest; maybe I'm rewriting a theorem; maybe I'm adding a new lecture. Anyway, all these can be done more or less independently, and when one depends on the other, I can safely edit the root without creating lots of unnecessary conflicts. When conflicts do arise, they are easy to resolve as a non-emergency-matter because merge conflicts themselves are a first class part of Jujutsu's change model. I can go work on something else and come back to fix the conflicts, etc.
Jon Sterling
npub1hf…9ls8k
2026-01-25 22:21:40 UTC
in reply to nevent1q…hqku
Author Public Key
npub1hfga8wmley5fzqtttpeupd8hc6s92rykfmzktm8zfdhu9h8exvqsj9ls8kPublished at
2026-01-25 22:21:40 UTCEvent JSON
{
"id": "03914d56d8f03d8f844e5f30ff9b1001b083ab494ea2a57c377dd23dad136dab",
"pubkey": "ba51d3bb7fc92891016b5873c0b4f7c6a0550c964ec565ece24b6fc2dcf93301",
"created_at": 1769379700,
"kind": 1,
"tags": [
[
"p",
"06e17c43fb77671c8e51e7f02c872701fa733489b4db3b1d3c6a1683e30e4684",
"wss://relay.ditto.pub"
],
[
"p",
"f6e5f6bc41d8187e776540f170adeab6d0d71bf2f6e396e4a3a73394e20b0e1c",
"wss://relay.ditto.pub"
],
[
"e",
"a811102659d9eca4571ae40c59d363ff49855a6e3d8c1480fd43bad754d45812",
"wss://relay.ditto.pub",
"reply"
],
[
"proxy",
"https://mathstodon.xyz/users/jonmsterling/statuses/115958068083770243",
"activitypub"
],
[
"client",
"Mostr",
"31990:6be38f8c63df7dbf84db7ec4a6e6fbbd8d19dca3b980efad18585c46f04b26f9:mostr",
"wss://relay.ditto.pub"
]
],
"content": "nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqqmshcslmwan3erj3ulczepe8q8a8xdyfkndnk8fudgtg8ccwg6zqfcr0xq The thing that is helping is basically that Jujutsu provides a local rebase workflow that is more reliable. One way to think about Jujutsu is that whereas Git has one unnamed staging area, Jujutsu has unlimited staging areas that can be stacked on each other in a DAG. Of course, these \"staging areas\" are just the mutable (i.e. non-pushed) commits in your working copy.\n\nWhat makes this so nice is that I can reliably edit one of these changes and all the dependent changes get automatically rebased. This is theoretically possible in Git, and I'm fairly good at it, but for some reason in Git it always leads to lots of suffering and cascading failures. One important difference from Git, however, is that the even though the changes have a different commit ID, they keep a separate identity (the \"change id\") across all edits and rebases.\n\nAnyway, when working on my forest, I sometimes have three or four changes going on at a time. Maybe I'm fixing a certain class of typo across the whole forest; maybe I'm rewriting a theorem; maybe I'm adding a new lecture. Anyway, all these can be done more or less independently, and when one depends on the other, I can safely edit the root without creating lots of unnecessary conflicts. When conflicts do arise, they are easy to resolve as a non-emergency-matter because merge conflicts themselves are a first class part of Jujutsu's change model. I can go work on something else and come back to fix the conflicts, etc.",
"sig": "15cfc77bf725f345babcbde4808531442b0d565228b472e8f1b5cd7bff33892489c9dc7cfd7d825e85a2619de802bf55c1f8f6a824d6211ffa9c13ef09968e58"
}