What I've learned from jj • Hacker News Board

Re: What I've learned from jj

#31

Post by Izkata » Sat, May 03, 2025, 12:50 AM UTC

epage wrote: post #30

cornstalks wrote: post #26

> The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant. I loathe GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer. And you know what? I love it. Yes, there's some overhead. But I can u…

My ideal workflow is commits are as small as possible and PRs "tell a story", meaning that they provide the context for a commit. I will split up a PR into - Individual steps a a refactor, especially making any moves their own commits - I add tests *before* the feature (passing, showing the old behavior) - The actual fix or feature commit is tiny, with the diff of the tests just demontstrating how behavior changed Th…

As someone who has often had to dig into the history to figure out what happened, I always want to see at least this. And I wouldn't be opposed to seeing it broken down even more as it was worked on. Not one big squash merge that hides what really happened.

I'll also add one more to your list: Any improvements that came out of the review but stayed in that merge should each be individual commits. I've seen hard-to-trigger bugs get introduced from what should have been just a style improvement.

Re: What I've learned from jj

#32

Post by hbay » Sat, May 03, 2025, 1:01 AM UTC

Skimmed the article so I admittedly can't speak to much to the content of it, but just wanted to give my 2c on working on individual things after spending a lot of time working with a stack-based VCS in mercurial/sapling -- jj felt pretty hard to get used to and after a couple of weeks I gave it up. I think it needs a competitive visualization tool to Interactive Smartlog.

I've settled on using Interactive Git Log in VSCode.

Re: What I've learned from jj

#33

Post by cole_ » Sat, May 03, 2025, 1:06 AM UTC

Surprised no one has mentioned https://graphite.dev/ yet. Our team uses it for stacked PRs, and it works really well.

Re: What I've learned from jj

#34

Post by FridgeSeal » Sat, May 03, 2025, 1:19 AM UTC

abcd_f wrote: post #6

A thing to learn from JJ's performance is that not everyone is cut out to direct Star Wars movies.

Or Star Trek.

Re: What I've learned from jj

#35

Post by sashank_1509 » Sat, May 03, 2025, 1:23 AM UTC

Sounds a lot like what’s being used internally at Google

Re: What I've learned from jj

#36

Post by wmf » Sat, May 03, 2025, 1:36 AM UTC

cadamsdotcom wrote: post #18

It’s clear from multiple posts over years that jj has a better UX than plain git. Why not just merge it into git?

It's too different. At best you could make it an off-by-default mode.

And I'm sure there are some people who actually prefer Sapling or raw git.

Re: What I've learned from jj

#37

Post by cornstalks » Sat, May 03, 2025, 1:37 AM UTC

stavros wrote: post #28

cornstalks wrote: post #26

> The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant. I loathe GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer. And you know what? I love it. Yes, there's some overhead. But I can u…

Is this what Gerrit does?

Pretty much, yes. I've only used Gerrit a few times so my direct experience is limited.

Re: What I've learned from jj

#38

Post by marssaxman » Sat, May 03, 2025, 1:43 AM UTC

wtallis wrote: post #27

cornstalks wrote: post #26

> The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant. I loathe GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer. And you know what? I love it. Yes, there's some overhead. But I can u…

Worrying about individual commits is also what makes it possible for you to later use git bisect without going crazy.

How often do you find that command useful?

In ~18 years of git use, I have never needed it, but I see it mentioned often as an important reason to handle commits in some certain way. I wonder what accounts for the difference.

Re: What I've learned from jj

#39

Post by nonethewiser » Sat, May 03, 2025, 1:52 AM UTC

cornstalks wrote: post #26

> The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant. I loathe GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer. And you know what? I love it. Yes, there's some overhead. But I can u…

This encourages commit size to grow drastically.

Re: What I've learned from jj

#40

Post by nonethewiser » Sat, May 03, 2025, 1:56 AM UTC

As entrenched as git is, I feel like its only a matter of time until it's dethroned.

The basic workflow is fine. And there are some very powerful features. But then you try find the parent of a given branch and you're left wondering how the f#!@ thats so hard.

It's definitely nit picking. It's probably 85-90% of what you want it to be. But there is definitely enough room for improvement to warrent moving beyond it. I think the workflows and integratoins (github, gitlab, etc.) make it stickier as well. I just dont think we should assume everyone is just going to use git for the next 20+ years.