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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

221–230 of 552 posts

Re: Jujutsu for busy devs

#221

Post by 1718627440 »

baq wrote: post #159
ants_everywhere wrote: post #65

Earlier quoted context omitted.

Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that…

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. jj doesn't have the concept of a non-committed file. instead you don't track the HEAD as the tip of the branch (@ in jj), you track HEAD^ (jj: @-) or something earlier and since jj rebase isn't dumb as a rock you can relatively easily keep the w…

Can't this be a security risk as there might be secrets that should never be recorded by jj (You can probably configure this, but I want my software to only do what I tell it to, not do everything until I tell it not to.)

How does that work in practice, is there a daemon running constantly and monitoring? How does that interact with other users and changes from other computers?

Re: Jujutsu for busy devs

#222

Post by RUnconcerned »

normie3000 wrote: post #173
sethammons wrote: post #168

Earlier quoted context omitted.

Nice commits can really tell a development story that makes reviews easier. That said, I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release. A very, very large problem at five out of six companies I have worked at is casual code improvement and refactoring. Devs would say, "we will ad…

> That company had vastly better code. It's very frustrating that what IMO is the inferior approach was producing better results in those teams!

It's because what you see as the inferior approach involves less effort and friction for the developers.

When you are told to separate general code improvements to another PR, or worse, to not do them, and create a Jira task for them so they can be adequately prioritized, it just saps your will to do so. You just won't do any improvements that fall outside the scope of the feature, because even just thinking about the hoops you have to jump through to get work done is mentally draining.

Re: Jujutsu for busy devs

#223

Post by 1718627440 »

stouset wrote: post #148
wredcoll wrote: post #107

Earlier quoted context omitted.

I want to appreciate this cool-sounding new tool, but everything you've said sounds exactly the same as using git rebase, what am I missing?

Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks. And it sucks even worse when you screw up the conflict resolution halfway through and have to start over from scratch. Rebases also don't play nicely with stacked branche…

> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks

You can use git commit --fixup to record what you want to change in an earlier commit.

> start over from scratch

rerere

> Branches based off your original changes don't get rewritten

As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.

Re: Jujutsu for busy devs

#224

Post by exclipy »

Disposal8433 wrote: post #115
esafak wrote: post #61

Earlier quoted context omitted.

Do you use an IDE with git support but not jujitsu? I do (intellij), and I'm not sure how useful it would be.

I've always hated the git CLI, and that's why I used Jetbrains tools or Sublime Merge. Now that I switched to jj (colocated with a get repo, very useful), I went back to using the CLI again for jj and I don't miss the graphical tools.

But how do you split commits? Command line tools for splitting commits suck because they force you to look at one hunk at a time without getting the context from the rest of the change.

Re: Jujutsu for busy devs

#225

Post by stavros »

emresahin wrote: post #219

I tried jj a few days but I noticed my lazygit based workflow and scripts already make me productive enough not to deal with another mental model. jj looks cool in general, I'd start with it if I were just going into this _version control_ thing but for most of us older folks, that doesn't provide enough motivation to change.

Eh, I can see how, if you use GitButler, the porcelain is fairly irrelevant to you, but a few days ago I decided to try Jujutsu, asked Claude how I could do a few things that came up (commit, move branches, push/pull to Github). It took me ten minutes to become proficiend in Jujutsu, and now it's my VCS of choice.

I still use Lazygit for the improved diffing, but, as long as you don't mind being in detached HEAD all the time, there's really no issue with doing that. JJ interoperates fine with git, but why would I use the arcane git commands when JJ will do the same thing much more straightforwardly?

Also, the ability to jump from branch to branch with all my uncommitted files traveling with me is a godsend. Now I can breeze between feature development, bug fixing, copy changing, etc just by editing the commit I want. If I want multiple AI agents working on that stuff, I just make a worktree and get on with it.

Not to mention that I am really liking the fact that I can describe changes (basically add commit messages) before I'm done with them, so I can see them in the tree.

JJ is just all around great.

Re: Jujutsu for busy devs

#226

Post by simonmic »

Lyngbakr wrote: post #5

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that cha…

jj's auto staging isn't always desirable. I feel jj docs and evangelists should make clearer that it's easy to turn off by default, by adding this to ~/.jjconfig:

    [snapshot]
    auto-track = "none()"

Re: Jujutsu for busy devs

#227

Post by 1718627440 »

stouset wrote: post #146
fouc wrote: post #92

Lately I've been hearing more people are getting into jj because of how much easier it is to keep track of the code generated with tools like cursor or claude code.

Yes! I have found it incredibly helpful when using an agent. It's a great case for the "staging-area" style workflow. I `jj new` an empty revision where the LLM can go hog-wild. When I'm generally happy with the LLM's work, I make a new revision. Then I ask it to make some improvements. Sometimes I have to discard those. No problem, I just `jj abandon` the whole thing. Sometimes I like a few pieces; I `jj squash -i`…

I wonder when LLMs will start messing with VCS. That will be fun :-/

Re: Jujutsu for busy devs

#228

Post by tgv »

stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

> I have seen a 100% conversion rate from everyone who gave it a serious try.

Cognitive dissonance is a thing.

Re: Jujutsu for busy devs

#229

Post by baq »

1718627440 wrote: post #221
baq wrote: post #159

Earlier quoted context omitted.

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. jj doesn't have the concept of a non-committed file. instead you don't track the HEAD as the tip of the branch (@ in jj), you track HEAD^ (jj: @-) or something earlier and since jj rebase isn't dumb as a rock you can relatively easily keep the w…

Can't this be a security risk as there might be secrets that should never be recorded by jj (You can probably configure this, but I want my software to only do what I tell it to, not do everything until I tell it not to.) How does that work in practice, is there a daemon running constantly and monitoring? How does that interact with other users and changes from other computers?

Every jj invocation stores a snapshot before doing anything else - thus anytime you run jj, you tell it to store a snapshot in the local repo.

I don't see a problem with secrets TBH. .gitignore is respected if that's what you have in mind. Otherwise store your secrets out of tree (you probably should with git too, anyway.)

Re: Jujutsu for busy devs

#230

Post by exclipy »

I tried it for a bit and went back to git-branchless (https://github.com/arxanas/git-branchless).

git-branchless is just a better set of tools for working on a git repo so local tools like the JetBrains git integration will work just fine.

It operates on a similar philosophy to Jujutsu (make it easy to manipulate the commit tree) and the authors did exchange ideas with each other.

Post reply on HN