What I've learned from jj • Hacker News Board

Re: What I've learned from jj

#81

Post by jmmv » Sat, May 03, 2025, 1:34 PM UTC

esafak wrote: post #44

cole_ wrote: post #33

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

How do they compare?

Jujutsu is “just” a piece of software that you install, and it is free and open source. Graphite.dev is a service, and it is not free, but as a service it gives you features that Jujutsu cannot like automatically merging stacked PRs.

For something as fundamental as source control in this day and age, I’d go with the former open source option (and have recently been learning Jujutsu)…

Re: What I've learned from jj

#82

Post by theusus » Sat, May 03, 2025, 1:43 PM UTC

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.

Re: What I've learned from jj

#83

Post by n4r9 » Sat, May 03, 2025, 2:20 PM UTC

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

Re: What I've learned from jj

#84

Post by vlovich123 » Sat, May 03, 2025, 2:55 PM UTC

marssaxman wrote: post #38

wtallis wrote: post #27

Earlier quoted context omitted.

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.

I think it’s not that you couldn’t have used it but because you discount it it wasn’t something you reached for. If you flip the script as something that’s out there and explicitly look for opportunities to use it it’s there. Alternatively, you don’t structure your commits carefully and thus git bisect for you is a mess that would pull up a giant amount of code anyway.

Heck, I used it yesterday because I had a PR where I was cleaning things in the C++ build system where things stopped working in CI in weird ways I couldn’t figure out but was fine locally. I used bisect locally to figure out which commits to test. You just have to think that a blind bisect search is going to be more effective than trying to spot check the commits that are a problem (and for tricky bugs this is often the case because your intuition can mislead you).

I’ve also used it to find weird performance regressions I couldn’t figure out.

Re: What I've learned from jj

#85

Post by jFriedensreich » Sat, May 03, 2025, 3:01 PM UTC

sigmonsays wrote: post #46

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

jj seems to be the slowly evolving winner of these alternatives. It just does things on top of git that you cannot do by using git directly no matter how well you know git.

Re: What I've learned from jj

#86

Post by SoftTalker » Sat, May 03, 2025, 3:07 PM UTC

rcxdude wrote: post #64

marssaxman wrote: post #38

Earlier quoted context omitted.

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.

Occasionally, but when it's useful, it's very useful. But generally only if most commits are buildable and roughly functional, otherwise it becomes a big pain (as does any manual process of finding what change introduced a regression).

Same. I've only done bisect debugging a few times. I'm almost always able to use more traditional debugging especially if I have a good idea about where the bug must be from behavior.

Bisects are good when the bug is reproducible, you have a "this used to work and now it doesnt" situatiuon, and the code base is too big or too unfamiliar for you to have a good intuition about where to look. You can pretty quickly get to the commit where the bug first appears, and then look at what changed in that commit.

Re: What I've learned from jj

#87

Post by jFriedensreich » Sat, May 03, 2025, 3:08 PM UTC

JJ just surpassed a milestone for me personally where there were no hick-ups for more than 6 months and it feels genuinely superior to git and also to sapling for performance, stability and UX. If you ever considered switching i think it might be now. Colocated mode does not feel like a second class citizen and works really well too so there is always the option to use a sophisticated git client like fork for certain tasks. VisualJJ is also a great albeit not open source vscode extensio n that is slowly catching up to ISL. (If you are used to ISL and think visualJJ looks empty and lacks features: most things are hidden in the context menu which takes some getting used to.)

Re: What I've learned from jj

#88

Post by Munksgaard » Sat, May 03, 2025, 3:25 PM UTC

dorian-graph wrote: post #10

Like the author, I'd appreciate a stacked PRs approach , integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are "linked" to the jj changes. So 1 change per PR or it could even be multiple. I've lately become a huge fan of git-spice, that just works .

Graphite.dev does this, and it works great.

Re: What I've learned from jj

#89

Post by arccy » Sat, May 03, 2025, 3:36 PM UTC

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.

some of us do `git add .`, you can't ship an unbuildable commit because you forgot something

what you should have is support for local, gitignore-able config files

Re: What I've learned from jj

#90

Post by marssaxman » Sat, May 03, 2025, 3:56 PM UTC

overfeed wrote: post #59

marssaxman wrote: post #38

Earlier quoted context omitted.

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.

How do you trace the origin of breaking changes, especially those arising from integration problems? For fairly busy codebases (>10 commits per day), and a certain subset of regressions, bisect is invaluable in finding the root cause. you can always do it the "hard way", so it's not the only way

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.

There was one git-using startup I worked for which had a merge-recklessly development style, and there was one occasion when I could have used `git bisect` to disprove my coworker's accusation that I had thoughtlessly broken the build (it was him, actually, and, yuck - what a toxic work environment!), but the commit in question was like HEAD~3 so it would probably have taken me longer to use git bisect than to just test it by hand.