5 ms·

Well, time to bite the bullet and learn jujutsu over the holidays

by spooky_action 10mo ago

wrs 10mo ago
It’s not so much biting the bullet as eating the delicious chocolate.
- MarcelOlsz 10mo ago
  This is the comment that did it for me. I love chocolate. I'm in.
_lvbh 10mo ago
Took me a month to learn jujutsu. Was initially a skeptic but pulled through. Git was always easy to me. Its model somehow just clicks in my brain. So when I first switched to jj, it made a lot of easy things hard due to the lack of staging (which is often part of my workflow). But now I see the value & it really does make hard things easy. My commit history is much cleaner for one.
Phlogistique 10mo ago
Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.
- ninjha 10mo ago
  jj-spr solves this, although it is still pretty buggy: https://github.com/LucioFranco/jj-spr https://github.com/LucioFranco/jj-spr
  - samhh 10mo ago
    There’s also jj-stack. I don’t know how they compare. This is something GitHub should be investing time in, it’s so frustrating.
    - paradox460 10mo ago
      And tangled.sh supports JJ stacks out of the box
      - brw 10mo ago
        Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow. I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration. Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over. [1] https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless [2] https://mergify.com https://mergify.com
- aabhay 10mo ago
  jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically. The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.
  - jacobegold 10mo ago
    Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`
    - koreth1 10mo ago
      Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.
ninjha 10mo ago
I was scared to learn but then a coworker taught me the 4 commands I care about (jj new, jj undo, jj edit, jj log) and now I can't imagine going back to plain git. Obviously the working tree should be a commit like any other! It just makes sense!
paradox460 10mo ago
Do it. It's absolutely worth it. You can pick it up in 30 minutes and have full proficiency in an afternoon
tomasreimers 10mo ago
Love JJ and think you should learn it because it's fun - but Graphite's not going anywhere

Well, time to bite the bullet and learn jujutsu over the holidays

wrs 10mo ago

It’s not so much biting the bullet as eating the delicious chocolate.

MarcelOlsz 10mo ago
This is the comment that did it for me. I love chocolate. I'm in.

_lvbh 10mo ago

Took me a month to learn jujutsu. Was initially a skeptic but pulled through. Git was always easy to me. Its model somehow just clicks in my brain. So when I first switched to jj, it made a lot of easy things hard due to the lack of staging (which is often part of my workflow). But now I see the value & it really does make hard things easy. My commit history is much cleaner for one.

Phlogistique 10mo ago

Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.

ninjha 10mo ago
jj-spr solves this, although it is still pretty buggy: https://github.com/LucioFranco/jj-spr https://github.com/LucioFranco/jj-spr
- samhh 10mo ago
  There’s also jj-stack. I don’t know how they compare. This is something GitHub should be investing time in, it’s so frustrating.
  - paradox460 10mo ago
    And tangled.sh supports JJ stacks out of the box
    - brw 10mo ago
      Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow. I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration. Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over. [1] https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless [2] https://mergify.com https://mergify.com
aabhay 10mo ago
jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically. The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.
- jacobegold 10mo ago
  Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`
  - koreth1 10mo ago
    Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.

ninjha 10mo ago

I was scared to learn but then a coworker taught me the 4 commands I care about (jj new, jj undo, jj edit, jj log) and now I can't imagine going back to plain git. Obviously the working tree should be a commit like any other! It just makes sense!

paradox460 10mo ago

Do it. It's absolutely worth it. You can pick it up in 30 minutes and have full proficiency in an afternoon

tomasreimers 10mo ago

Love JJ and think you should learn it because it's fun - but Graphite's not going anywhere