7 ms·

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming

by oefrha 1y ago

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.

ModernMech 1y ago
Oh wow, they were going for "magic" with that name?? I read it as "maggot".
dcre 1y ago
I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros. I’ve never used magit but I used GitUp (https://gitup.co/ https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
- chrchr 1y ago
  There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
  - aardvark179 1y ago
    Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.
    - 1718627440 1y ago
      And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?
      - steveklabnik 1y ago
        jj doesn’t support it in the sense that there’s no special index feature. You can use a workflow where you have a commit represent the index (and that’s basically the most common workflow). This means you don’t need a separate feature, you just use the tools that slice and dice any commit with your “index”.
      - baq 1y ago
        It isn’t that it doesn’t support it, it kinda does, but the recommended workflow is such that the index is simply pointless.
  - pm215 1y ago
    As an stgit user, this seems like a weird workflow to me. I never want to have that many uncommitted changes just floating around that will eventually belong to multiple commits. If I'm halfway through something and realise "oh, it would be good to do xyz first" I don't want to have xyz's changes and my half-way-through changes all mixed up -- I want to pop the half-way-through stuff, do the xyz stuff and commit it, then re-push the half-way-through stuff to keep working. If I'm looking at a diff and picking out parts of it then I've done something wrong -- I have a tool for doing it but I only need to use it every couple of months... I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.
    - steveklabnik 1y ago
      This sort of flow is very nice in jj, primarily because of the “no index” plus “auto commit” behavior, I’ll regularly go “oh yeah I want to go do that” and I’m about to just go do it and then come back to right where I left off, since my work is already saved.
      - pm215 1y ago
        Yeah, I get the impression jj is good for this, and if I were using raw git then it would be a massive upgrade. Luckily for me stgit already does what I want in this area so I have no strong need to investigate alternatives, but if stgit ever bitrots then jj might be a useful next thing.
        jpgrayson 1y ago
        StGit maintainer here. I have been a jj user for over a year now. It has proven superior to StGit for all of my workloads. I even use jj when maintaining StGit. An incomplete list of wins vs StGit includes: - jj makes managing multiple branches fluid, whereas stg has limited tools for managing patches between stacks. 'stg pick' is largely all there is. It's a real dance to move a patch between stacks. - jj has a much better system for naming changes. I'm super jealous of how jj solved this problem. StGit requires you to name the patches. I added the feature that allows StGit to refer to patches by relative or absolute index in addition to by name. jj's immutable change ids that can be referenced by unambiguous prefix is the correct answer to this problem. - 'jj rebase' is so vastly superior to stg push/pop/sink/float for reordering changes that I don't even know where to start. It wasn't immediately obvious to me just how flexible, simple, and powerful 'jj rebase' is when I first started using jj, I have learned that it is in its own league relative to StGit's stack ordering story. - Similarly 'jj squash' makes 'stg squash' look amateurish. I could go on. If you're a StGit user, you owe it to yourself to give jj a proper try.
CGamesPlay 1y ago
Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e2afb508a83f9ede49040320d/files/.config/jj/config.toml#L110 https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...
pkulak 1y ago
If you open your favorite git editor in a jj repo, everything you stage will become a new commit, everything you revert will… revert. I still use Sublime Merge rather frequently.
baq 1y ago
In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.
- oefrha 1y ago
  > For people like me who stage/commit often and judiciously Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation. * Or we can completely change how we write code…
  - xintron 1y ago
    I see your point, but this feels like a difference in workflow philosophy, especially with AI-assisted coding becoming more common. With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits. Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.
    - oefrha 1y ago
      With AI there’s even more reason to have ergonomic splitting if you care about quality commits, since unless you always write the perfect focused prompt, AI can over-generate for the scope of a single commit, so sooner or later you need to split that commit during the cleanup process you mentioned.
Balinares 1y ago
If you understand why having a great UX on top of bare git is valuable, you have understood 95% of what's to understand about jj.
- jbstack 1y ago
  But there are dozens of great UXs on top of Git already, so if that's 95% of what jj is about then you seem to be making an argument for jj adding very little value. My understanding is that jj offers more than just UX enhancements.
  - Balinares 1y ago
    Interesting, isn't it? There you are, and yet none of those dozens are garnering anywhere near the same amount of attention and enthusiasm as jj. And yet, it's genuinely mostly just that -- a novel CLI on top of the same storage backend as git. Sometimes it doesn't take that much to bring about a paradigm shift, I suppose. Just a few new ideas with a great implementation, and there you are -- they've just got to be the right new ideas. That being the hard part.
cryptonector 1y ago
> Plus I rebase a lot Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.
- baq 1y ago
  This does not compute, like at all. jj rebase is half the reason to use it at all. Everything git does with the commit dag, jj does the same at worst, sometimes better. It actually sounds like you're confusing jj with something else.
- steveklabnik 1y ago
  I’m curious to hear more about what you find opinionated, I think one struggle I’ve had teaching jj to people is that it’s extremely flexible.
  - cryptonector 1y ago
    I'll have to look again. Last I looked at it I felt like jj was a straightjacket.
    - steveklabnik 1y ago
      It's all good. If you do give it a try and feel like letting me know how it goes, I'm genuinely interested. No worries if not :)

by oefrha 1y ago

ModernMech 1y ago

Oh wow, they were going for "magic" with that name?? I read it as "maggot".

dcre 1y ago

I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros. I’ve never used magit but I used GitUp (https://gitup.co/ https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.

chrchr 1y ago
There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
- aardvark179 1y ago
  Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.
  - 1718627440 1y ago
    And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?
    - steveklabnik 1y ago
      jj doesn’t support it in the sense that there’s no special index feature. You can use a workflow where you have a commit represent the index (and that’s basically the most common workflow). This means you don’t need a separate feature, you just use the tools that slice and dice any commit with your “index”.
    - baq 1y ago
      It isn’t that it doesn’t support it, it kinda does, but the recommended workflow is such that the index is simply pointless.
- pm215 1y ago
  As an stgit user, this seems like a weird workflow to me. I never want to have that many uncommitted changes just floating around that will eventually belong to multiple commits. If I'm halfway through something and realise "oh, it would be good to do xyz first" I don't want to have xyz's changes and my half-way-through changes all mixed up -- I want to pop the half-way-through stuff, do the xyz stuff and commit it, then re-push the half-way-through stuff to keep working. If I'm looking at a diff and picking out parts of it then I've done something wrong -- I have a tool for doing it but I only need to use it every couple of months... I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.
  - steveklabnik 1y ago
    This sort of flow is very nice in jj, primarily because of the “no index” plus “auto commit” behavior, I’ll regularly go “oh yeah I want to go do that” and I’m about to just go do it and then come back to right where I left off, since my work is already saved.
    - pm215 1y ago
      Yeah, I get the impression jj is good for this, and if I were using raw git then it would be a massive upgrade. Luckily for me stgit already does what I want in this area so I have no strong need to investigate alternatives, but if stgit ever bitrots then jj might be a useful next thing.
      - jpgrayson 1y ago
        StGit maintainer here. I have been a jj user for over a year now. It has proven superior to StGit for all of my workloads. I even use jj when maintaining StGit. An incomplete list of wins vs StGit includes: - jj makes managing multiple branches fluid, whereas stg has limited tools for managing patches between stacks. 'stg pick' is largely all there is. It's a real dance to move a patch between stacks. - jj has a much better system for naming changes. I'm super jealous of how jj solved this problem. StGit requires you to name the patches. I added the feature that allows StGit to refer to patches by relative or absolute index in addition to by name. jj's immutable change ids that can be referenced by unambiguous prefix is the correct answer to this problem. - 'jj rebase' is so vastly superior to stg push/pop/sink/float for reordering changes that I don't even know where to start. It wasn't immediately obvious to me just how flexible, simple, and powerful 'jj rebase' is when I first started using jj, I have learned that it is in its own league relative to StGit's stack ordering story. - Similarly 'jj squash' makes 'stg squash' look amateurish. I could go on. If you're a StGit user, you owe it to yourself to give jj a proper try.

CGamesPlay 1y ago

Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e2afb508a83f9ede49040320d/files/.config/jj/config.toml#L110 https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...

pkulak 1y ago

If you open your favorite git editor in a jj repo, everything you stage will become a new commit, everything you revert will… revert. I still use Sublime Merge rather frequently.

baq 1y ago

In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.

oefrha 1y ago
> For people like me who stage/commit often and judiciously Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation. * Or we can completely change how we write code…
- xintron 1y ago
  I see your point, but this feels like a difference in workflow philosophy, especially with AI-assisted coding becoming more common. With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits. Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.
  - oefrha 1y ago
    With AI there’s even more reason to have ergonomic splitting if you care about quality commits, since unless you always write the perfect focused prompt, AI can over-generate for the scope of a single commit, so sooner or later you need to split that commit during the cleanup process you mentioned.

Balinares 1y ago

If you understand why having a great UX on top of bare git is valuable, you have understood 95% of what's to understand about jj.

jbstack 1y ago
But there are dozens of great UXs on top of Git already, so if that's 95% of what jj is about then you seem to be making an argument for jj adding very little value. My understanding is that jj offers more than just UX enhancements.
- Balinares 1y ago
  Interesting, isn't it? There you are, and yet none of those dozens are garnering anywhere near the same amount of attention and enthusiasm as jj. And yet, it's genuinely mostly just that -- a novel CLI on top of the same storage backend as git. Sometimes it doesn't take that much to bring about a paradigm shift, I suppose. Just a few new ideas with a great implementation, and there you are -- they've just got to be the right new ideas. That being the hard part.

cryptonector 1y ago

> Plus I rebase a lot Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.

baq 1y ago
This does not compute, like at all. jj rebase is half the reason to use it at all. Everything git does with the commit dag, jj does the same at worst, sometimes better. It actually sounds like you're confusing jj with something else.
steveklabnik 1y ago
I’m curious to hear more about what you find opinionated, I think one struggle I’ve had teaching jj to people is that it’s extremely flexible.
- cryptonector 1y ago
  I'll have to look again. Last I looked at it I felt like jj was a straightjacket.
  - steveklabnik 1y ago
    It's all good. If you do give it a try and feel like letting me know how it goes, I'm genuinely interested. No worries if not :)