Hacker News Reader

Comment by xlii | Hacker News Reader

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/

View on HN

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.

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.

I've seen that you can read one commit at a time, but never anything for reviewing (or diffing between them if they change) - is there a UI beyond just clicking on the list of commits?

Though I forget if you can even comment in the individual commits in that view. Complex multi-commit PRs have generally been a nightmare on GitHub in my experience.

You can comment on the individual commits' changes, but you can't comment on the commit (e.g. its message) itself. I believe you can do this in Gerrit.

Which means it's probably all I have seen - so you can't approve commits either, or track file-reading progress through commits (I think? i.e. "viewed file X at commit Y, but not at commit Z"), or diff changes to a commit (e.g. by order/message) after a rebase, just "you can see the current commit history". Not sure I'd consider that "can review one commit at a time", just "can read one commit at a time". "Review" means "there is support for this thing as a first class entity" imo, and that ain't what github is offering, nor anything even close to it.

That's true, but acceptance is still all or nothing.

When chaining commits it's possible to (for example) have a function that does THING and then have another PR that have a function that uses first one.

It's somewhat PITA when team has no-dead-code hard rule, but otherwise it's quite manageable and invites rich feedback. Reviewer and feedback can focus on atomic change (in example: function that does THING) and not on a grand picture.

But I also often use method of logical PRs and even written about it: https://xlii.space/eng/pr_trick/

You do if you find yourself in a team where PRs are squash-merged. :-(

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

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...

As the mythical doctor once said, "don't do that". My sympathies if you're on a team that requires it.

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

My peers are my reviewers...

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.

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.

And `jj undo`, so nothing is terrifying.

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)

I mean `git reflog` is right there! But jj is awesome, agreed

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.

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.

It's the one I keep going to LLM for, others like rebase are muscle memory at this point.

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

Submodules are cursed. I feel bad for you that you have to work in a repo that uses them.

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.

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

Not natively, but you can still use the regular git commands to update them, and it works.

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!

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.

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.

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

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.

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.

Samesies - need a Majjit before I can consider trying it out.

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

How do you handle publishing the stack?

It depends on what you're publishing to, but works with most other tools by using a bookmark for each publish target.

There’s tooling like 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.

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

Reply on news.ycombinator.com