4 ms·

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers w

by xlii 9mo ago

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained together). Git is great as a backend, but Jujutsu shines as a frontend. [0]: https://www.jj-vcs.dev/latest/ https://www.jj-vcs.dev/latest/

vlovich123 9mo ago
How do you handle publishing the stack?
- dcre 9mo ago
  There’s tooling like https://github.com/LucioFranco/jj-spr https://github.com/LucioFranco/jj-spr for managing stacks of PRs, but for stacks of 2 or 3 it’s not too bad to do it manually.
  - vlovich123 9mo ago
    I’ve not had any luck with that tool in terms of creating meaningfully reviewable prs. I’m hoping I can maybe leverage graphite for the stack generation while authoring everything in jj. We’ll see how that goes
- wocram 9mo ago
  It depends on what you're publishing to, but works with most other tools by using a bookmark for each publish target.
_flux 9mo ago
I think I'd love to use Jujutsu, but I enjoy Magit (for Emacs) too much to entertain the thought of switching :/. Besides, Magit rebasing is also pretty sweet.
- turboponyy 9mo ago
  Samesies - need a Majjit before I can consider trying it out.
- skulk 9mo ago
  I used to think like this, but then I realized: jj-mode.el exists[0] and you can still use magic since it's still a git repo underneath. Seriously, don't let this hold you back. [0]: https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el
  - _flux 9mo ago
    I took a look at both, and I think I'd need the jj split function (comparable to staging individual lines) to be implemented in jj-mode to match my use of magit.
    - skulk 9mo ago
      You can already do this if you just open up your change in magit and repeatedly commit pieces of it. I agree it's not super ergonomic since it leaves an old change behind and it requires using magit on top of jj-mode but it's 90% of the way there.
Zambyte 9mo ago
Also been using Jujutsu for about 2 years. I feel like I have learned so much about how git actually works by simply not using git.
kps 9mo ago
And `jj undo`, so nothing is terrifying.
- mamcx 9mo ago
  And if a major problem, `jj op log` + `jj op log restore` fix it. This is the major super power of jj: Before I need to nuke the git repo on bad rebases (not chance in hell I can find how undo the massive 20+ steps bad rebase)
  - smw 9mo ago
    I mean `git reflog` is right there! But jj is awesome, agreed
- Aperocky 9mo ago
  well git reflog is that, annoying, yes, but we have LLM so I don't actually need to remember how all the command syntax exactly like back in 2019.
  - darknavi 9mo ago
    Is git reflog that bad to use? It just lists a bunch of commit hashes. Find the one you want and hard reset to it.
    - Aperocky 9mo ago
      It's the one I keep going to LLM for, others like rebase are muscle memory at this point.
mamcx 9mo ago
+1 `jj` is the only tool that make me use `rebase` personally. Before, I see as the punishment given by my team wishes :)
grokys 9mo ago
Does it support submodules yet? That was the thing that stopped me using it last time I checked.
- steveklabnik 9mo ago
  Not natively, but you can still use the regular git commands to update them, and it works.
- tcoff91 9mo ago
  Submodules are cursed. I feel bad for you that you have to work in a repo that uses them.
  - bkmq 9mo ago
    What is the problem with submodules? I like to use them because it means the code I need from another repo remains the same until I update it. No unexpected breaking changes.
    - tcoff91 9mo ago
      Using a package manager to share code between repos has worked far better for me than submodules. This comment sums up the issues better than I could: https://news.ycombinator.com/item?id=31792396 https://news.ycombinator.com/item?id=31792396
yawaramin 9mo ago
> reviewers will love you, peers will hate 8 small PRs that are chained together My peers are my reviewers...
jon-wood 9mo ago
You don't have to chain 8 PRs together, Github tries really hard to hide this from you but you can in fact review one commit at a time, which means you don't need to have a stack of 8 PRs that cascade into each other.
- Liskni_si 9mo ago
  You do if you find yourself in a team where PRs are squash-merged. :-(
  - unshavedyak 9mo ago
    Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s
    - Liskni_si 9mo ago
      Happens on merge, sure, but the end result is that you kinda lose the individual commits. You can still find them in the PR, but you won't see them in the git history, so git blame will just point you to the one big squashed commit. If you, however, open a chain of 8 PRs, and merge them in the right order, the individual commits will be persisted in the git history. Potentially worth it if you like to have a "story" of several commits...
    - jon-wood 9mo ago
      As the mythical doctor once said, "don't do that". My sympathies if you're on a team that requires it.
- unshavedyak 9mo ago
  Yup, that's what my team does. It works wonderfully, and it fits well with Github's "large PR" mindset imo. It could be a bit better in the Github UI, but so can most things. I vastly prefer it to individually reviewing tons of PRs. The funny thing about this debate for me is that i find it comes down to the committer. If the committer makes small commits in a stacked PR, where each commit is a logical unit of work, part of the "story" being told about the overall change, then i don't personally find it's that useful to stack them. The committer did the hard part, they wrote the story of changes in a logical, easy to parse manner. If the story is a mess, where the commits are huge or out of logical order, etc - then it doesn't matter much in my view.. the PR(s) sucks either way. I find stacked PRs to be a workflow solution to what to me is a UI problem.
BeetleB 9mo ago
The key thing to point out is that jujutsu is a rebase-based workflow, and no on who uses jujutsu ever worries about rebasing (they may not even be aware of it). It's a good demonstration of a tool that got rebase right, unlike git. Pre-jujutsu, I never rebased unless my team required it. Now I do it all the time. Pre-jj, I never had linear history, unless the team required it. Now most of my projects have linear history. A better UI makes a huge difference.
nickkell 9mo ago
I'm a big fan of rebasing to keep the commit history clean and as a form of self-discipline when coding to make sure I'm grouping the changes atomically. I will try to give Jujutsu a go based on your recommendation!
stouset 9mo ago
The comments sections in git posts vs. jj posts are always hysterical to me. If there’s a jj post on HN, people come out of the woodworks to say that git is easy and it’s crazy to suggest that anyone finds it difficult or confusing. Also people saying they’ve figured out git is super usable if you only ever use commit, merge, pull. Then you have git posts where everyone talks about how hard some basic things are, how easy it is to mess up your repo, how frustrating rebase is, etc. It’s fun to watch.

by xlii 9mo ago

vlovich123 9mo ago

How do you handle publishing the stack?

dcre 9mo ago
There’s tooling like https://github.com/LucioFranco/jj-spr https://github.com/LucioFranco/jj-spr for managing stacks of PRs, but for stacks of 2 or 3 it’s not too bad to do it manually.
- vlovich123 9mo ago
  I’ve not had any luck with that tool in terms of creating meaningfully reviewable prs. I’m hoping I can maybe leverage graphite for the stack generation while authoring everything in jj. We’ll see how that goes
wocram 9mo ago
It depends on what you're publishing to, but works with most other tools by using a bookmark for each publish target.

_flux 9mo ago

I think I'd love to use Jujutsu, but I enjoy Magit (for Emacs) too much to entertain the thought of switching :/. Besides, Magit rebasing is also pretty sweet.

turboponyy 9mo ago
Samesies - need a Majjit before I can consider trying it out.
skulk 9mo ago
I used to think like this, but then I realized: jj-mode.el exists[0] and you can still use magic since it's still a git repo underneath. Seriously, don't let this hold you back. [0]: https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el
- _flux 9mo ago
  I took a look at both, and I think I'd need the jj split function (comparable to staging individual lines) to be implemented in jj-mode to match my use of magit.
  - skulk 9mo ago
    You can already do this if you just open up your change in magit and repeatedly commit pieces of it. I agree it's not super ergonomic since it leaves an old change behind and it requires using magit on top of jj-mode but it's 90% of the way there.

Zambyte 9mo ago

Also been using Jujutsu for about 2 years. I feel like I have learned so much about how git actually works by simply not using git.

kps 9mo ago

And `jj undo`, so nothing is terrifying.

mamcx 9mo ago
And if a major problem, `jj op log` + `jj op log restore` fix it. This is the major super power of jj: Before I need to nuke the git repo on bad rebases (not chance in hell I can find how undo the massive 20+ steps bad rebase)
- smw 9mo ago
  I mean `git reflog` is right there! But jj is awesome, agreed
Aperocky 9mo ago
well git reflog is that, annoying, yes, but we have LLM so I don't actually need to remember how all the command syntax exactly like back in 2019.
- darknavi 9mo ago
  Is git reflog that bad to use? It just lists a bunch of commit hashes. Find the one you want and hard reset to it.
  - Aperocky 9mo ago
    It's the one I keep going to LLM for, others like rebase are muscle memory at this point.

mamcx 9mo ago

+1 `jj` is the only tool that make me use `rebase` personally. Before, I see as the punishment given by my team wishes :)

grokys 9mo ago

Does it support submodules yet? That was the thing that stopped me using it last time I checked.

steveklabnik 9mo ago
Not natively, but you can still use the regular git commands to update them, and it works.
tcoff91 9mo ago
Submodules are cursed. I feel bad for you that you have to work in a repo that uses them.
- bkmq 9mo ago
  What is the problem with submodules? I like to use them because it means the code I need from another repo remains the same until I update it. No unexpected breaking changes.
  - tcoff91 9mo ago
    Using a package manager to share code between repos has worked far better for me than submodules. This comment sums up the issues better than I could: https://news.ycombinator.com/item?id=31792396 https://news.ycombinator.com/item?id=31792396

yawaramin 9mo ago

> reviewers will love you, peers will hate 8 small PRs that are chained together My peers are my reviewers...

jon-wood 9mo ago

You don't have to chain 8 PRs together, Github tries really hard to hide this from you but you can in fact review one commit at a time, which means you don't need to have a stack of 8 PRs that cascade into each other.

Liskni_si 9mo ago
You do if you find yourself in a team where PRs are squash-merged. :-(
- unshavedyak 9mo ago
  Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s
  - Liskni_si 9mo ago
    Happens on merge, sure, but the end result is that you kinda lose the individual commits. You can still find them in the PR, but you won't see them in the git history, so git blame will just point you to the one big squashed commit. If you, however, open a chain of 8 PRs, and merge them in the right order, the individual commits will be persisted in the git history. Potentially worth it if you like to have a "story" of several commits...
  - jon-wood 9mo ago
    As the mythical doctor once said, "don't do that". My sympathies if you're on a team that requires it.
unshavedyak 9mo ago
Yup, that's what my team does. It works wonderfully, and it fits well with Github's "large PR" mindset imo. It could be a bit better in the Github UI, but so can most things. I vastly prefer it to individually reviewing tons of PRs. The funny thing about this debate for me is that i find it comes down to the committer. If the committer makes small commits in a stacked PR, where each commit is a logical unit of work, part of the "story" being told about the overall change, then i don't personally find it's that useful to stack them. The committer did the hard part, they wrote the story of changes in a logical, easy to parse manner. If the story is a mess, where the commits are huge or out of logical order, etc - then it doesn't matter much in my view.. the PR(s) sucks either way. I find stacked PRs to be a workflow solution to what to me is a UI problem.

BeetleB 9mo ago

The key thing to point out is that jujutsu is a rebase-based workflow, and no on who uses jujutsu ever worries about rebasing (they may not even be aware of it). It's a good demonstration of a tool that got rebase right, unlike git. Pre-jujutsu, I never rebased unless my team required it. Now I do it all the time. Pre-jj, I never had linear history, unless the team required it. Now most of my projects have linear history. A better UI makes a huge difference.

nickkell 9mo ago

I'm a big fan of rebasing to keep the commit history clean and as a form of self-discipline when coding to make sure I'm grouping the changes atomically. I will try to give Jujutsu a go based on your recommendation!

stouset 9mo ago

The comments sections in git posts vs. jj posts are always hysterical to me. If there’s a jj post on HN, people come out of the woodworks to say that git is easy and it’s crazy to suggest that anyone finds it difficult or confusing. Also people saying they’ve figured out git is super usable if you only ever use commit, merge, pull. Then you have git posts where everyone talks about how hard some basic things are, how easy it is to mess up your repo, how frustrating rebase is, etc. It’s fun to watch.