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

411–420 of 552 posts

Re: Jujutsu for busy devs

#411

Post by Zambyte »

IshKebab wrote: post #382
Zambyte wrote: post #354

Earlier quoted context omitted.

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

> create multiple directories (workspaces) backed by a single repository at different commits This is `git worktree`. They don't work with submodules but submodules are a disaster that should be avoided anyway so probably no big loss there.

Ah, I was not familiar with that feature in git. In that case, I'll swap out jj workspaces for sparse checkouts :-)

Re: Jujutsu for busy devs

#412

Post by stouset »

seivan wrote: post #177
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…

The way I understand it, its for those who can't help but to fix B while working on A and want to make sure that they are two different PRs? The way I do it is after B is done, I just create a new branch and point B to A in the PR. A is pointing to dev/master/upstream. Does JJ make this workflow more convenient?

Yep! And it makes it convenient even when you need to make changes or add new commits onto A. B is constantly stitched up to remain a child of A and incorporate its fixes.

It also makes it simple and easy to split B and A apart such that both their parents are `main` if they’re unrelated.

You can also go hog-wild. I was working on a big refactor recently. I made independent changes A, B, C, and D (each one to three commits). I then wanted to work on code that assumed all of these commits were available, so I made a merge commit E that combined them. I then made changes F that depended on that refactor, so was a child of E.

Managing this was simple. If I needed to make updates or tweaks to A-D, E and F were updated to incorporate them automatically. `jj absorb` even meant that doing these types of changes was almost zero work: I could make a bunch of changes and the tool would know in which parent commit they belonged.

None of this was merged in yet. When I was ready, PRs went out for A-D. When they each merged into `main`, E became a no-op and was discarded. F became its own PR. This is something I never would have done in git because having multiple threads of unmerged code is a colossal hassle.

Re: Jujutsu for busy devs

#413

Post by qudat »

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…

> You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git.

I used it for a week and switched back to `git`. Most of its hallmark features are not something I use that often.

Re: Jujutsu for busy devs

#414

Post by stouset »

DrBazza wrote: post #323
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…

>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. Agreed. Having used SCCS, CVS, Subversion, VSS, Perforce, Clearcase, Accurev (the weirdest of the lot), Mercurial and Git, I'll move when the market decides what has critical mass and my job needs it. jj feels a bit like learning a Dvorak keyboard and then being in an office of qwerty. Jobs wa…

I still know git. I work at entirely git shops. Nobody has ever come to me with a problem I’ve caused, but people have come to me to ask how to switch.

I am also the guy who gets asked with doing crazy git things when the need comes up. I have another post here where a tricky and slow filter-branch that our company needed to do on a repo was a simple and obvious three-liner in jj.

Re: Jujutsu for busy devs

#415

Post by RUnconcerned »

ceedan wrote: post #258
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!

The approach didn't drive quality. 1 team cared about their code and felt empowered to improve it, the other didn't.

The majority of people care about the quality of their work when they are starting off. Not caring is a learned behavior. When you repeatedly get reprimanded for it, you learn not to care as a way of protecting your mental health from taking even more damage.

Re: Jujutsu for busy devs

#417

Post by [deleted] »

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.

[deleted]

Re: Jujutsu for busy devs

#418

Post by packetlost »

sunshowers wrote: post #395
packetlost wrote: post #394

Earlier quoted context omitted.

> Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack I think this is what `git rebase --edit-todo` is for. >Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy. Fair enough. `jj` probably isn't right…

Been a long time since I used git, but --edit-todo only changes what's still to come, right? It doesn't let you go back and edit earlier commits in the stack.

Ah, yeah it does only allow you to modify the remaining todos :/

Re: Jujutsu for busy devs

#419

Post by andrewaylett »

christophilus wrote: post #327
weinzierl wrote: post #124

Earlier quoted context omitted.

"You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. " Reporting in. Doesn't mean I will not end up with jj eventually, but so far I always went back to git after a while. For me it is the staging area and the workflow it allows. Most people hate it and love jj because it does away with it. That is just not me. I don't see the staging area as a hack that was necessary…

I’m similar. On the other hand, tools like jj seem great for people who spend a lot of time refining and perfecting every commit so that their repo history is pristine. I’m not one of those people. My git hygiene is atrocious. I have git halitosis. But functionally, it’s fine. Everything is in the git history and is recoverable. That’s about all I care about. Also, I don’t have the capacity to juggle a lot in my mind…

Jujutsu might look like it's for people who want to perfect their commits and juggle a lot in their minds -- but in my case (and anecdotally in others' too) it's because it lets us easily do things which would require that mindset/ability with plain Git.

In Git, I need to keep in mind all the different things I'm working on and which branch goes where, or I wind up with a monster PR with a chain of commits that mix everything up enough that it's even more effort to pull the PR apart to be reviewable. Ask my colleagues how I know that :P.

With jj, I don't feel that I'm putting more effort into organising my changes -- quite the opposite -- not least because there's very little book-keeping involved in parking something that's in progress or coming back to it later. And when I come to ask for a review, I've got separate changes I can push as smaller PRs, and I can easily pull the right sets of changes out to make each one reviewable.

I think the biggest improvement is that if I just need to look at something else for a couple of minutes then come back, I can `jj new main` to switch and not bring my changes with me then I can `jj edit ` to get my working copy back into the state it was in before, with all my old changes.

I'm pretty sure none of my colleagues have started using it (although they're free to) but I can confidently say (because I've asked) that they've noticed the difference in my work and prefer the more focused changes.

Re: Jujutsu for busy devs

#420

Post by 0points »

Zambyte wrote: post #365
palata wrote: post #358

Earlier quoted context omitted.

> to reset or view the repo at a previous state What about `git reflog`?

That lets you see previously checked out revisions. Jujutsu keeps track of all previous repo state. In git, you can pull a new remote branch, delete that branch, and push the deletion. If you want to get that branch back, git reflog will only save you if you checked out that commit. If you didn't, you're SOL. Jujutsu will let you undo the delete operation, restore the repo to a state where the branch existed, or view…

That might be cool, actually.

FWIW, I cheated on a previous job for months by working 10% or so, then faking git commit data to spread it out across the week before sending a PR.

Thank you "git commit --amend --no-edit --date xxx"

Post reply on HN