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

231–240 of 552 posts

Re: Jujutsu for busy devs

#231

Post by baq »

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!

paperwork and red tape results in lower velocity. sometimes this is what you want.

note this is also true in software engineering.

Re: Jujutsu for busy devs

#232

Post by 1718627440 »

baq wrote: post #229
1718627440 wrote: post #221

Earlier quoted context omitted.

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

Right now I can mess around like I want, because I am in charge what gets tracked, I need to specify it explicitly. This would loose that.

Re: Jujutsu for busy devs

#233

Post by 1718627440 »

nchmy wrote: post #205
1718627440 wrote: post #180

Earlier quoted context omitted.

> The subsequent revisions are updated automatically How do you make sure, that a commit isn't changed under you, because someone thought, it would be a good idea to change an earlier revision? I think having immutable commits including all the previous history is a feature, not a bug.

Jj treats any public/pushed commits/branches as immutable by default.

How does it know that? Does it also work, when I clone or pull instead?

Is that only enforced on the committer side? I mean git also doesn't force push by default, but that still means someone else can do that and I need to notice it.

Re: Jujutsu for busy devs

#234

Post by arccy »

oxidant wrote: post #71
0cf8612b2e1e wrote: post #8

Earlier quoted context omitted.

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode be…

Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.

you've obviously never encountered code which only works when println is added.

Re: Jujutsu for busy devs

#235

Post by baq »

arp242 wrote: post #15
doritosfan84 wrote: post #3

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

> By and large, it works well enough.

be wary of the stockholm syndrome. I too love git, but it is a very cumbersome tool for some workflows.

Re: Jujutsu for busy devs

#236

Post by nchmy »

1718627440 wrote: post #233
nchmy wrote: post #205

Earlier quoted context omitted.

Jj treats any public/pushed commits/branches as immutable by default.

How does it know that? Does it also work, when I clone or pull instead? Is that only enforced on the committer side? I mean git also doesn't force push by default, but that still means someone else can do that and I need to notice it.

I don't have answers for you. But the docs are useful and people in their discord are helpful as well

Re: Jujutsu for busy devs

#237

Post by globular-toast »

1718627440 wrote: post #214
globular-toast wrote: post #151

Earlier quoted context omitted.

Yeah this is good if you, for some reason, rebase then merge without fast forwarding. I never understood doing this. If I'm going to be ignoring those commits when bisecting then they are useless commits just using up disk space IMO. Does it work well with a classic merge workflow? I haven't worked that way (without rebasing) for a long time.

For me a merge is about grouping commits, when you have just a list of commits, the list can be very long. That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.

The whole point of bisect is to make it quicker to find a point in a potentially long list of commits. Finding the feature first then bisecting within the branch is only going to make it slower, and requires you to manually restart the bisect.

I use the commit message to add ticket numbers to things to group commits.

Re: Jujutsu for busy devs

#238

Post by baq »

1718627440 wrote: post #232
baq wrote: post #229

Earlier quoted context omitted.

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

Right now I can mess around like I want, because I am in charge what gets tracked, I need to specify it explicitly. This would loose that.

this is not as important as you're used to. I've been there, I've used git since early 2010s and yes autostaging was preposterous at first. in practice, it's barely relevant: the workflow changes from 'I pick what is tracked' to 'I pick what is pushed'.

Re: Jujutsu for busy devs

#239

Post by KingMob »

exclipy wrote: post #230

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.

It seems like a lot more than they "did exchange ideas".

Arxanas, the lead dev of git-branchless, is also one of the major devs and maintainers of jj. He's active on the jj discord, and just last month put out a call on github for a jj side conference during Git Merge 2025.

Re: Jujutsu for busy devs

#240

Post by whatagreatboy »

palata wrote: post #143
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…

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim , the b…

How much time do you spend resolving merge conflicts between multiple team members?
Post reply on HN