Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I've learned from jj

zerowidth.com

Post reply on HN
Print view View original

131–140 of 140 posts

Re: What I've learned from jj

#131

Post by wtallis »

EnPissant wrote: post #121
Dylan16807 wrote: post #116

Earlier quoted context omitted.

> If you treat a PR as a unit of work, then there is nothing to bisect. You're bisecting the history of PR merges.

You ignored the part where I claimed that without squash merging, people will just do it manually with git rebasing or amending.

You're ignoring the part where squashing commits leaves you with fewer, larger commits to search through, while merging or rebasing leaves you with a more fine-grained commit history that allows a git bisect to better narrow down what changes broke something.

Re: What I've learned from jj

#132

Post by nchmy »

ramon156 wrote: post #129
nchmy wrote: post #23

Earlier quoted context omitted.

Check out jjui - it is VASTLY better, and the dev is extremely open and responsive to feature requests. https://github.com/idursun/jjui

What makes it extremely better?

Far more commands/shortcuts, capabilities etc... Just try the various tools out. I am not aware of anything that comes close.

Re: What I've learned from jj

#133

Post by n4r9 »

ramon156 wrote: post #130
n4r9 wrote: post #83

> You don’t need to explicitly tell jj about what you’ve done in your working copy, it’s already tracked. This removes the need for an “index” or staging area Does this mean that you have to proactively remember and undo any config file changes you made e.g. while fixing an issue in a test environment? Sounds a little risky.

Agreed, and these comments fail to remember you sometimes need code changes to debug. Its nice to stage/unstage code changes, and gitignore won't help u there

Exactly. 'git add' forces you to locally review which code changes you actually need, and catch any debug code, attempted fixes, a bit of whitespace you typed while thinking, refactorings that didn't actually turn out to help etc... . Otherwise it's up to the reviewer to spot.

Re: What I've learned from jj

#134

Post by sfink »

Dylan16807 wrote: post #115
mb7733 wrote: post #105

Earlier quoted context omitted.

> I don't really ever find myself having to do that. I guess it's been a long time since I worked in an environment which did not use an "only merge to main after passing CI" workflow, and back then we weren't using git, anyway. You _never_ have bugs that slip through the test suite? That is extremely impressive / borderline impossible. Even highly tested gold-standard projects like SQLite see bugs in production. And…

Bugs that slip through the test suite and it's important to trace the origin and it requires building more than a couple best-guess versions to find it. And even then, if it wastes an hour or two once in a blue moon that's not a big motivator for workflow changes. You're skeptical of a far stronger claim than the one they actually made.

Performance regressions often match all of those constraints, at least in an active project.

Re: What I've learned from jj

#135

Post by sfink »

EnPissant wrote: post #127
Dylan16807 wrote: post #126

Earlier quoted context omitted.

They make it very clear that they are praising small commits, and squash merge commits are usually not small . Squashing is the opposite of what they want. The preference they have is not exactly a problem with github PRs, but github PRs are much more likely to review a big pile of code at once. The amount of code being reviewed at once is a meaningful and extremely objective measure, and that's the thing they're con…

There is zero chance that any shop that reviews individual commits is not squashing them. I probably wont be able to respond to any more comments. Dang put a slowban on my account because he interpreted one of my comments as right wing.

At Mozilla, we review individual commits and do not squash them. This is probably true of anyone using one of the forges capable of handling patch stacks. ("Probably" because the shop may or may not review everything!) Once in a great while, I will keep the commits separate for review and squash for landing, but that's because I intentionally left things in a half-complete state for ease of review.

When you're looking back at why something was done in a certain way, the review view is more useful than either the squashed view or the stream-of-work view. A human put effort into making it understandable, so it's no surprise that it's more understandable.

Re: What I've learned from jj

#136

Post by EnPissant »

sfink wrote: post #135
EnPissant wrote: post #127

Earlier quoted context omitted.

There is zero chance that any shop that reviews individual commits is not squashing them. I probably wont be able to respond to any more comments. Dang put a slowban on my account because he interpreted one of my comments as right wing.

At Mozilla, we review individual commits and do not squash them. This is probably true of anyone using one of the forges capable of handling patch stacks. ("Probably" because the shop may or may not review everything!) Once in a great while, I will keep the commits separate for review and squash for landing, but that's because I intentionally left things in a half-complete state for ease of review. When you're lookin…

So if someone reviews your changes and you both agree to rename a variable, is that its own commit or do you squash it?

Re: What I've learned from jj

#137

Post by sfink »

EnPissant wrote: post #136
sfink wrote: post #135

Earlier quoted context omitted.

At Mozilla, we review individual commits and do not squash them. This is probably true of anyone using one of the forges capable of handling patch stacks. ("Probably" because the shop may or may not review everything!) Once in a great while, I will keep the commits separate for review and squash for landing, but that's because I intentionally left things in a half-complete state for ease of review. When you're lookin…

So if someone reviews your changes and you both agree to rename a variable, is that its own commit or do you squash it?

Squash. But note that we don't use github PRs, we use Phabricator with support for stacks, so we're likely talking about somewhat different things.

I'm talking about a forge that allows some sort of persistent reviewable unit that can change over time. Phabricator revisions, jj changes, and at least Gerrit has the same thing. There isn't a single unit of review, there are two: the bug and the individual changes. The bug is associated with a stack of changes. An individual change initially corresponds to a commit, but when you rename a variable, you update the commit for that change. jj and I guess git call that squashing, hg calls it amending.

The author does work, useful work, to break down everything that needs to change for that bug into a series of reviewable changes, preferably not breaking the build or tests in the middle of the series, but that's negotiable.

So we may not be disagreeing on anything. If by "commit" you mean one item in a patch stack, then yes we squash. But we do not squash the different changes within a bug, whether or not they change during review. If there's a change that does some refactoring to prepare, then a change to add a new API, then a change to add users and tests of those users, then we review those separately and do not squash for landing.

It is definitely my preferred way of working. I don't want to see a dozen fixup commits, nor do I want to see a giant change that touches everything at once. It's a happy middle ground where the author decides what the reviewer and later debuggers need to look at and what they can skip.

Re: What I've learned from jj

#138

Post by EnPissant »

sfink wrote: post #137
EnPissant wrote: post #136

Earlier quoted context omitted.

So if someone reviews your changes and you both agree to rename a variable, is that its own commit or do you squash it?

Squash. But note that we don't use github PRs, we use Phabricator with support for stacks, so we're likely talking about somewhat different things. I'm talking about a forge that allows some sort of persistent reviewable unit that can change over time. Phabricator revisions, jj changes, and at least Gerrit has the same thing. There isn't a single unit of review, there are two: the bug and the individual changes. The…

It’s been a while since I have used a phabricator, but gh with squash merge is extremely similar. You review the PR as a whole, even though the branch may consist of any number of commits or merges. GH presents you the diff between the target branch (usually main) and your branch, you never see the individual commits except in the timeline or if you want to. When you merge the PR it just adds a single commit on top of main. When i moved from phab to github I preferred it because a PR is just a normal branch and you never have to destroy history of that branch with rebase or ammend until you merge it.

Re: What I've learned from jj

#139

Post by theusus »

baq wrote: post #110
theusus wrote: post #82

I used jj for a bit. It messed up my code, put everything in staged and what not. I might try it again when it's stable.

It's by design. It's quite stable, too. You were probably confused by assuming it works like git, it really doesn't when you're working on a change. It kinda starts looking like git when changes are committed and pushed to master/main.

I know what I said.

Re: What I've learned from jj

#140

Post by medler »

sigmonsays wrote: post #46

i'm growing tired of these git alternatives. I feel like people should just learn to use git.

jj is compatible with git repos while being faster to learn and easier to use. There’s basically no reason for anyone to learn git now that this exists.
Post reply on HN