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

351–360 of 552 posts

Re: Jujutsu for busy devs

#351

Post by ben0x539 »

riwsky wrote: post #295
ben0x539 wrote: post #275

Earlier quoted context omitted.

I'm sure if I did the proper time investment I would enjoy jj. I've heard basically only good things about it in casual conversation. So far, my experience has been that I tried it, immediately got really annoyed that it automatically adds every untracked file that's not gitignored to the current commit, and was advised that I might want to stay with git if that's a problem. That said, I struggle a bit with learning…

Mental model: “everything is a commit”. Commits are commits. Stashes are commits. The working tree is a commit. The index doesn’t exist, because it’s unnecessary. The data model is technically of revisions, which are stable across operations like rebases (which change the underlying git commit). How to conceptualize a branch: as a bookmark of a specific commit.

Yeah, I think that extra layer of revision identity is giving my intuition trouble, like it's obvious it needs to be there but the consequences are still percolating through my head.

Re: Jujutsu for busy devs

#352

Post by baq »

ants_everywhere wrote: post #257
baq wrote: post #238

Earlier quoted context omitted.

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

You know your evangelists have gone haywire when they're explaining that your requirements are wrong instead of listening.

I'm far from being an evangelist. I'm trying out jj in one repo out of several and it's far from perfect - but it is useful though, and it does make sense. The requirement of being able to not commit everything by default is simply not necessary from a logical standpoint; if anything, it is itself evangelism that the git way is the right way. The truth is both work just fine, which has been my point all along.

Re: Jujutsu for busy devs

#353

Post by palata »

gabrielgio wrote: post #341
palata wrote: post #333

Earlier quoted context omitted.

> You are in forum in a post about jj saying there is no reason to use jj I honestly am not. I am genuinely interested. Everytime there is a post about jj I'm about to try, and then I see a comment like yours, saying "with jj you just use the intuitive syntax `jj git push -r '(trunk\(?.\).x#@ | @@.^)'`, which is a lot simpler than knowing about this weird concept of stash" and it makes me think that maybe, I'll try a…

> I honestly am not. You literately are, look at you comments. > I am genuinely interested. If you are interest in learning you should take people words on good faith, my comment on "jj git push -r '(trunk()..@ | @::)'" is complex operation to update many stacked PRs not compared to local git index operations. Also in my comment I mentioned revsets and the "-r". It is a language to query logs which you should've chec…

> just to bash on jj for some reason

Actually, to be blunt (you're already offended anyway): what I'm saying is that I find (personal opinion) that many evangelists here (you included) don't sell jj really well. If so many people are actual fans of jj, there must be something there. I'm just struggling to find it between the "you're probably too dumb to understand a stash so you should use jj" and the "let me explain to you this great concept that jj has which allows you to undo changes in a way that sounds like git cannot do exactly that".

So no, I'm not criticising jj :-). And I'm not convinced I need it.

Re: Jujutsu for busy devs

#354

Post by Zambyte »

stavros wrote: post #268
palata wrote: post #254

Earlier quoted context omitted.

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

> because there's no single thing that you can do with jj that you can't with git.

- jj undo, jj op restore, and jj --at-op to reset or view the repo at a previous state

- create multiple directories (workspaces) backed by a single repository at different commits

These are the only things I can think of off the top of my head that you can do with jj that you can't do with git.

Re: Jujutsu for busy devs

#355

Post by dmsnell »

sshine wrote: post #324
__turbobrew__ wrote: post #317

Earlier quoted context omitted.

How fast I can deliver value is almost never gated by my VCS, so why should I try? In total I maybe lose a few minutes a month to VCS impedance mismatch, and I am merging on average ~4-5 PRs a day. For sure git is hard to learn for beginners and there could be an alternative which is easier to pick up (maybe jj) but for those who know how git works internally and are proficient with it I don’t see it being worth the…

> How fast I can deliver value is almost never gated by my VCS Oh, the number of times I do git commit --fixup ...searches `git log` and pastes`... && \ git rebase -i --autosquash ...that same commit^... I waste several half minutes several times per day in periods! Another time-consuming thing is context-switching from a feature branch with staged/unstaged changes. If you're good with worktrees, you can largely avoi…

You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message.

    git rebase -i --rebase-merges --keep-base trunk
This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvements from jj, except it’s just git.

This article from Andrew Lock on stacked branches in git was a great inspiration for me, and where I learned about --update-refs:

https://andrewlock.net/working-with-stacked-branches-in-git-...

Re: Jujutsu for busy devs

#356

Post by baq »

Cthulhu_ wrote: post #350
baq wrote: post #235

Earlier quoted context omitted.

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

But does Jujutso solve those workflows, or does it add a layer on top that you need to figure out on top of what you already know about Git? I don't run into any issues with Git during my day to day. Some things could be a bit more ergonomic but that's because I'm too stubborn to learn or set up some aliases or look up how to do it. Following this tutorial, I can't say jujutsu feels like an improvement. More complica…

jj solves one particular issue I have with git and github: truly easy (not just 'possible') rebasing of branches and editing commits which are not heads. You need to commit conflicts to solve this properly, which is something git really doesn't want you to do.

Re: Jujutsu for busy devs

#357

Post by WXLCKNO »

sngz wrote: post #139
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 always go back to using mercurial for personal projects. Better than both

Not typing hg is the best part of my day

Re: Jujutsu for busy devs

#358

Post by palata »

Zambyte wrote: post #354
stavros wrote: post #268

Earlier quoted context omitted.

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

> because there's no single thing that you can do with jj that you can't with git. - jj undo, jj op restore, and jj --at-op to reset or view the repo at a previous state - create multiple directories (workspaces) backed by a single repository at different commits These are the only things I can think of off the top of my head that you can do with jj that you can't do with git.

> to reset or view the repo at a previous state

What about `git reflog`?

Re: Jujutsu for busy devs

#359

Post by sesm »

stouset wrote: post #154
palata wrote: post #143

Earlier quoted context omitted.

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

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…

> It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently.

Git has worktrees for that. If a parallel change is done in a separate worktree, it can be built and tested independently, which, I guess, is important for kernel developers, who are the initial target audience for git.

Re: Jujutsu for busy devs

#360

Post by riwsky »

ramon156 wrote: post #147
kadhirvelm wrote: post #91

I’ve had a lot of success using https://graphite.dev/ . Been pretty easy to pick up and slots right into our usual GitHub workflow. I end up using the vscode extension to manage it. Anyone have opinions how jujutsu compares?

Isn't graphite a pr review tool that still uses git?

It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked PRs”. Slower; refuses to work from a detached HEAD; gets confused more easily by changes on the remote.
Post reply on HN