8 ms·

A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving co

A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later. - Manipulating commits is super easy (especially with jjui). I reorder commits all the time and move them between branches. Of course you can also squash and split commits, but that's already easy in git. Back when I was using git, I would rarely touch previous commits other than the occasional squash or rename. But now I frequently manipulate the commit history of my branch to make it more readable and organized. - jj acts as a VCS for your VCS. It has an operation log that is a history of the state of the git repository. So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone. - Unnamed branches is the feature that has changed my workflow the most. It's hard to explain, so I probably won't do it justice. Basically you stop thinking about things in terms of branches and instead just see it as a graph of commits. While I'm experimenting/exploring how to implement or refactor something, I can create "sub-branches" and switch between them. Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before. Hopefully this made some sense. Also note that jj is fully compatible with git. I use it at work and all my coworkers use git. So it feels more like a git client than a git replacement.

coldtea 5mo ago
All of these features sound like the recipe for a confusing nightmare! "You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later." "Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before."
- ncphillips 5mo ago
  Yeah I legit do not understand the appeal. I’m willing to be wrong but it’s not clicking with me at all
  - baq 5mo ago
    typical for experienced git users who already 'just don't do' things which git punishes you for; after a decade it's hard to even imagine any other way, not to mention that it might be better. been there, done that, jj is legit after letting go of (some of) git.
  - tcoff91 5mo ago
    Anonymous branches are amazing for when you are trying out a bunch of different approaches to a problem. As I search the space of possible solutions for what I'm really looking for, I end up with a tree of various approaches. Then when you rebase, the entire tree of anonymous branches can be rebased onto main in 1 command. This is why the first class conflicts and not having to resolve conflicts immediately is so important: when i'm rebasing, an entire tree of branches is getting rebased and so if you had to resolve conflicts right away it would be incredibly cumbersome, because I'm rebasing like 30+ commits and a bunch of anonymous branches in a single operation. I work on top of an octopus merge of all my in-flight PRs. ON top of that merge commit i have a bunch of anonymous branches with various things going on. When I'm ready to submit a PR, I take one of those anonymous branches and rebase it onto main and make it an additional parent of my 'dev-base' merge commit. Then i give that branch a name and submit it as a PR. Every day when I start working, I rebase this entire subgraph of branches in a single command onto main. all my PRs are up to date, all my anonymous branches are up to date, etc... Takes like 2 seconds. If some of my anonymous branches are in a conflicted state, that's ok, i don't have to deal with it until I want to work on that change again. These anonymous branches aren't confusing because they all show up in the default revset that is shown when looking at the jj log. I can easily browse through them with jjui TUI and instantly see which ones are what. It's really not confusing at all. https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
- steveklabnik 5mo ago
k4rnaj1k 5mo ago
[dead]
capitainenemo 5mo ago
I also like the powerful revision querying mechanisms that they pulled in from mercurial. They seem to work just like mercurial revset queries which can be used in various operations on sets of revisions. I would like them to have mercurial's awesome hg fa --deleted when it comes to history trawling, but apparently for it to work well, they also need to swap out git's diff format for mercurial's smarter one, so I'll be waiting on that for a while I suppose.
rasguanabana 5mo ago
> So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone. It’s possible to recover from these with git reflog, though.
- ersatz-matty 5mo ago
  `jj undo` compared to what exactly?
- BeetleB 5mo ago
  I've used git for years, and used reflog once or twice. I've used jj for only a year, and have used "jj undo" countless times. There's a huge benefit to having a simpler mental model.
- skribanto 5mo ago
  From my understanding git reflog works on refs and jj op log works on fhe repo as a whole. E.g. if I rebase some stacked branches then I want to undo it, with git I would reset each branch separately. With jj you can timetravel the state of the repo in ine command

coldtea 5mo ago

All of these features sound like the recipe for a confusing nightmare! "You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later." "Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before."

ncphillips 5mo ago
Yeah I legit do not understand the appeal. I’m willing to be wrong but it’s not clicking with me at all
- baq 5mo ago
  typical for experienced git users who already 'just don't do' things which git punishes you for; after a decade it's hard to even imagine any other way, not to mention that it might be better. been there, done that, jj is legit after letting go of (some of) git.
- tcoff91 5mo ago
  Anonymous branches are amazing for when you are trying out a bunch of different approaches to a problem. As I search the space of possible solutions for what I'm really looking for, I end up with a tree of various approaches. Then when you rebase, the entire tree of anonymous branches can be rebased onto main in 1 command. This is why the first class conflicts and not having to resolve conflicts immediately is so important: when i'm rebasing, an entire tree of branches is getting rebased and so if you had to resolve conflicts right away it would be incredibly cumbersome, because I'm rebasing like 30+ commits and a bunch of anonymous branches in a single operation. I work on top of an octopus merge of all my in-flight PRs. ON top of that merge commit i have a bunch of anonymous branches with various things going on. When I'm ready to submit a PR, I take one of those anonymous branches and rebase it onto main and make it an additional parent of my 'dev-base' merge commit. Then i give that branch a name and submit it as a PR. Every day when I start working, I rebase this entire subgraph of branches in a single command onto main. all my PRs are up to date, all my anonymous branches are up to date, etc... Takes like 2 seconds. If some of my anonymous branches are in a conflicted state, that's ok, i don't have to deal with it until I want to work on that change again. These anonymous branches aren't confusing because they all show up in the default revset that is shown when looking at the jj log. I can easily browse through them with jjui TUI and instantly see which ones are what. It's really not confusing at all. https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
steveklabnik 5mo ago

k4rnaj1k 5mo ago

[dead]

capitainenemo 5mo ago

I also like the powerful revision querying mechanisms that they pulled in from mercurial. They seem to work just like mercurial revset queries which can be used in various operations on sets of revisions. I would like them to have mercurial's awesome hg fa --deleted when it comes to history trawling, but apparently for it to work well, they also need to swap out git's diff format for mercurial's smarter one, so I'll be waiting on that for a while I suppose.

rasguanabana 5mo ago

> So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone. It’s possible to recover from these with git reflog, though.

ersatz-matty 5mo ago
`jj undo` compared to what exactly?
BeetleB 5mo ago
I've used git for years, and used reflog once or twice. I've used jj for only a year, and have used "jj undo" countless times. There's a huge benefit to having a simpler mental model.
skribanto 5mo ago
From my understanding git reflog works on refs and jj op log works on fhe repo as a whole. E.g. if I rebase some stacked branches then I want to undo it, with git I would reset each branch separately. With jj you can timetravel the state of the repo in ine command