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

511–520 of 552 posts

Re: Jujutsu for busy devs

#511

Post by rodrigodlu »

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 did that and went "back".

Most of the projects I do for money are on Github and Gitlab.

I got my hands on things like YT videos explaining, official docs, cheatsheets.

About 4 hours exploring, trying to use with some side projects.

I did the same decades ago from CVS/SVN to git (even tried Hg). At that time it was obvious the "revolution" + "evolution" effect. Also git provided some transition tools that were easier to use from my pov.

Now it's just "evolution".

I see the added power to work with different "branches" simultaneously, move commits in different order in a way that is easier to have some better management logic, etc.

This is basically compelling if you work on different facets on big monorepos.

But I want to work on one thing a time nowadays, do something reliable, instead several features simultaneously, even with AI assistance, so the gains are not that huge, yet.

Like you I ended up using git commands again naturally. Stopping using svn commands eons ago felt amazing.

Re: Jujutsu for busy devs

#512

Post by Zambyte »

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…

> Everything is in the git history and is recoverable.

How do you recover from accidentally deleting a branch that you never checked out? Assume it was deleted on known remotes also.

Re: Jujutsu for busy devs

#513

Post by Zambyte »

stouset wrote: post #427
exclipy wrote: post #224

Earlier quoted context omitted.

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.

jj uses a TUI for this that lets you navigate the entire set of changes.

Not only is the default behavior of `jj split` exceptionally good and not susceptible to the issue they described, but you can easily specify an external tools like the meld gui to offload these operations to as a configuration option.

Re: Jujutsu for busy devs

#514

Post by nchmy »

Levitz wrote: post #399
nchmy wrote: post #296

Earlier quoted context omitted.

The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? What other tools do people do that for? Not many. I see the most similar language and behaviour with regards to uv, which similarly revolutionized/simplified python tooling. Likewise mise, which makes it similarly frictionless to install and manage tooling and their versions across projects and system-wid…

>The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? To make a point? To prove that "they are right"? People do this constantly , tools, libraries, languages... All the time really.

You do you, friend

Re: Jujutsu for busy devs

#515

Post by nchmy »

Filligree wrote: post #455
nchmy wrote: post #289

Earlier quoted context omitted.

I have a bad habit, even still, of just working in one monster commit. It took me a few months to realize that I could use jj split to move specific files to a different commit. And then I'd sometimes squash them into related commits, rebase to move them around etc... But I just discovered interactive split, which lets you move specific lines and sections from different files in a commit to a different commit. So I'v…

One really nice trick you can do is: - Create multiple topic branches, one for each thing you're working on. - Now you probably want to work on item A while having B and C all available, so make a single merge commit (jj new a b c) to build on top of. - Create further commits on top of that, while you're working. - When you're cleaning up (ideally often), use squash --to or rebase --after to move those commits back t…

Yeah, I was already aware of megamerge. I use it.

But I'm still not disciplined enough to use it and other proper workflows consistently, especially when new features/topics spring up while working on another one. I just start working on it at the same time, and jj makes it simple to split it into its own commit and branch later.

Re: Jujutsu for busy devs

#516

Post by nchmy »

icorbrey wrote: post #477
Filligree wrote: post #455

Earlier quoted context omitted.

One really nice trick you can do is: - Create multiple topic branches, one for each thing you're working on. - Now you probably want to work on item A while having B and C all available, so make a single merge commit (jj new a b c) to build on top of. - Create further commits on top of that, while you're working. - When you're cleaning up (ideally often), use squash --to or rebase --after to move those commits back t…

Megamerges are awesome, but what really makes them magical is when you start using `jj absorb`, which automatically splits and squashes your commit down to the nearest unambiguous commits and leaves anything that doesn't have an obvious place to live

I've been trying absorb recently and have found it rarely does anything and I just resort to squashes. Any idea what might be going on?

Re: Jujutsu for busy devs

#517

Post by nchmy »

andrewaylett wrote: post #406
nchmy wrote: post #363

Earlier quoted context omitted.

Haha, fantastic. Also, if you didn't discover yet, you can use the arrow keys to unfold the different files and sections. Then select what you need, split the rest to new commit. As you know, even when just using the most basic functionality (new changes, merges, rebases) of jj, it's amazing. But then you just keep discovering other features and workflows - none of which require any incantations - that make it that m…

If you end up with a commit that's a number of small fix-ups to files edited in earlier commits, `jj absorb` will push changes up to whichever (mutable) commit last modified the file they're in.

Thanks. I've been trying it recently but it never seems to do anything, so I just do squashes. Any idea why this might be?

Re: Jujutsu for busy devs

#518

Post by nchmy »

deredede wrote: post #402
nchmy wrote: post #204

Earlier quoted context omitted.

There isn't really any "can't switch to another tool" when it comes to git + jj. You can use it today without anyone on your team knowing - other than that your PRs suddenly became much cleaner

Some people can't install arbitrary software on their employer's hardware.

That's unfortunate. Hopefully they'll be able to use jj on their own hardware, or with future employers

Re: Jujutsu for busy devs

#519

Post by steveklabnik »

1718627440 wrote: post #506
steveklabnik wrote: post #466

Earlier quoted context omitted.

Oh, since you said 'merge' I thought you meant like git merge. Amending a commit works the same way as git. The difference is just that the oplog will have the full history, including before you amended, so you can roll back easily.

So the history of the second commit gets discarded?

Ah, I see what you're saying. I think so, the evolog ends up showing that stuff was squashed elsewhere, I believe.

Re: Jujutsu for busy devs

#520

Post by frizlab »

BeetleB wrote: post #496
frizlab wrote: post #469

Earlier quoted context omitted.

> This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Relaxing this comment which is a bit aggressive: at least it’s how I work. YMMV.

> Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Again, see my other comment. It's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done."

> it's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done”

Neither. Rebasing is an atomic task, kinda like a commit.

Post reply on HN