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

261–270 of 552 posts

Re: Jujutsu for busy devs

#261

Post by jon-wood »

RUnconcerned wrote: post #222
normie3000 wrote: post #173

Earlier quoted context omitted.

> 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 th…

I don't know how but we need to get developers out of thinking of PRs as the smallest possible change unit. This is literally what commits are for, you do a chunk of work, and you have a commit which describes that chunk of work. If you've got cleanly isolated commits then when you come to reviewing the PR (or changeset as I'd much rather see them called) and someone questions the wisdom of including that particular change you can either modify the commit to satisfy the questions, or just pull it out of the changeset into it's own for later review without blocking merge of the wider feature.

Coincidentally jj makes this process much easier than it would be with git, it will very happily let you shift commits around between different branches, edit commits in place and cleanly rebase those edits onto subsequent commits, or split a messy commit into two commits that makes sense.

Re: Jujutsu for busy devs

#262

Post by ben0x539 »

latexr wrote: post #174
stouset wrote: post #130

Earlier quoted context omitted.

> In other words, I actually understand git, so I don't really need Jujutsu. This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj obsolete. I am (or was) a git expert. I’ve used it since pre-GitHub. I’ve written a git implementation. I know (or knew) the interface inside and out. I haven’t deleted and re-cloned a repo in as long as…

> This is kind of a poor take. Why? They’re sharing what they prefer in response to someone claiming that everyone who tries the other thing comes to prefer that. They’re offering a reply in context and not in the slightest saying everyone should follow what they do. > By all means use what you prefer! That’s exactly what they’re doing. > But understanding git and knowing the "right" way to use it doesn't make jj obs…

"In other words, I actually understand git, so I don't really need Jujutsu." sounds like jj is for people who don't understand git. That's naturally a contentious statement. It implies that jj doesn't offer anything to experts, which seems easy to contradict given how many people with git expertise will talk about getting value from jj. At worst, it could be taken as a bad faith kinda put-down, like, suggesting at jj users are worse at their job than people who make do with git. I think it's totally fair to take push back against how that was worded.

Re: Jujutsu for busy devs

#263

Post by stavros »

beng-nl wrote: post #164
stouset wrote: post #154

Earlier quoted context omitted.

For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated chan…

Wow, that does sound like a big improvement. My git commits are, when not forced to be otherwise, very sloppy, even though I’d prefer them to be neatly self contained. But as you imply, there is friction to making these in git, while making lots of unrelated changes in a single coding session. As an example of another ‘unnecessary’ switch, Pip with venvs was also completely solving all my Python dependency problems.…

I'm fairly confident you're going to love it. I'd read a few tutorials, but what finally clicked for me was just asking Claude what commands to use, and then explaining why.

Jujutsu finally made me understand git, after ten years of git use. It removes enough of the magic that I now know exactly what the commands do, and how the data model works.

Re: Jujutsu for busy devs

#264

Post by ants_everywhere »

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?

Secrets and client data. Regulated environments are very serious about client data. They can't go into source control either.

You can't change example.com/foo to point to example.com/baz and have it exist in source control. So to make the change you have to ignore every file that contains that string, test, then unignore. Or you have to make sure to absolutely remove every reference you've added to the merkle tree. Or you have to completely nuke your source control database after testing.

If you buy a used laptop hard drive from a remote worker at $BIG_REGULATED_CO because you want to find exploits, you're probably happier if they run jujutso than git because there will be a higher probability of finding secrets, client info, and other things that are forbidden from going into source control.

Re: Jujutsu for busy devs

#265

Post by Filligree »

dzaima wrote: post #192
MrJohz wrote: post #182

Earlier quoted context omitted.

If you leave the WIP head change blank, i.e. don't give it a description at all, then JJ will block you from pushing it unless you pass a specific flag, which is useful for sanity checking this sort of stuff. You might be able to configure JJ to also block commits with certain descriptions as well, which might be useful in your case.

I specifically have the WIP head description include the name of bookmark that it's attached to, if any (emulating git's non-detached head), so can't leave it empty (and generally wouldn't want to, for easy way to identify it, esp. with multiple workspaces). Some push blocker for certain commit name patterns would make sense to look into.

Should be simple enough, but look into trailers; the language already supports key-value maps in the commit description.

Re: Jujutsu for busy devs

#266

Post by tomasyany »

Don't want to sound old school, but git works perfectly fine.

The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

Re: Jujutsu for busy devs

#267

Post by 1718627440 »

KingMob wrote: post #252
1718627440 wrote: post #189

Earlier quoted context omitted.

Yeah this doesn't make sense in git terms. A commit is immutable, it never changes so it doesn't have a history, it's just always there.

That's still true in jj, too. But instead of commits, most of the time you're working with (the not greatly-named) "changes", which are a conceptual history of related commits. E.g., a single change ID points to the most recent commit in a list. As long as you keep editing on a change, it keeps accumulating commits under the hood. When you move to another change (via `jj commit`, `jj new`, etc), all your new commits…

Ah, so when people here talk about changing commits they are actually talking about changing changes (nicely named, indeed)?

What happens when you merge or split changes with the change history? It sounds a bit like applying a VCS on top of a VCS.

Re: Jujutsu for busy devs

#268

Post by stavros »

palata wrote: post #254
IshKebab wrote: post #215

Earlier quoted context omitted.

It's totally possible to have no issues with Git, e.g. if you are only using it for small or slow moving repos. There definitely are lots of big issues with Git though. I dunno how many jj solves but it doesn't seem unreasonable to suggest people move to a better system.

And I totally agree! And if jj works better for you, please use it! My point is just that I am yet to find a convincing example that would suggest that jj would improve my workflow. If people find it hard to stash a change, I don't tell them that they shouldn't get their shit together and not use jj. But I don't find it hard to stash a change, so why do I feel like jj evangelists try to convince me that something is…

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use.

That just results in less friction, and in you doing things with it that you couldn't be bothered to before. Yes, I can switch branches in git by stashing my changes, and then I can try to figure out the five-levels-deep stash stack, but with jj I just switch between branches without finishing working on them, because it just works and is easy.

Yes, with git you can technically have five branches open at the same time, and stash work to switch between them to work on one thing or the other, but it's so hard and finicky that you end up never doing it in reality. Or, you can say "I never need that", but is it that you never need it, or that your tools make it so hard that you just subconsciously never do it? For me, it was the latter, as now I'm switching between branches ALL THE TIME, just because it's easy.

Re: Jujutsu for busy devs

#269

Post by tomasyany »

jackblemming wrote: post #2

I must be getting old because I really don’t think git needs a simplified model. But hey, if people find value from this, more power to them. The blog is well written too.

Couldn't agree more. I guess we _are_ getting old after all.

I've been using git since ~2014, never really thought about changing it: it's clear, well documented, and ok difficult learning curve but hey that's the fun part.

Re: Jujutsu for busy devs

#270

Post by stavros »

xelxebar wrote: post #136
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…

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users. Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc. Also note that auxillary tooling, such as git-annex and…

Oh thanks for the heads up! I use jj but it would be a disaster if I committed something using it and git-crypt didn't work, and the secrets were all plaintext.
Post reply on HN