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

421–430 of 552 posts

Re: Jujutsu for busy devs

#421

Post by shaftway »

bjackman wrote: post #45
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…

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me.…

> I don't do my day-to-day work in the monorepo

Is this one of the repos that uses Gerrit? Does JJ play well with Gerrit?

IIRC Gerrit was super picky about amending commits and I was worried JJ's laissez faire attitude about creating git commits on demand wouldn't jive well.

Re: Jujutsu for busy devs

#422

Post by stouset »

palata wrote: post #335
nchmy wrote: post #293

Earlier quoted context omitted.

I've started, in this thread, likening it to Plato's Cave - people who are just using git are just seeing/using a blurry facsimile/projection of actual reality/possibilities. It's not a perfect analogy (jj is, I suppose, the projection, and people are chained in the cave), but it makes the point that there could be so much more. The matrix or people happily in a cult would be similar analogies. Perhaps even Stockholm…

This is exactly why it feels like evangelism: "people who don't love jj haven't seen the light/are uninformed/live in the dark age/must be in a cult". That kind of rhetoric makes me want to say "don't tell me I'm stupid if you are the one finding it hard to switch between git branches".

It is evangelism. Unabashedly. I think the Plato’s cave analogy is honestly apt.

Git was fine. I used git for ages. I loved its underlying model, and I think it’s brilliant. But it has a lot of sharp edges and a lot of tasks that are painful or frustrating, and people either opt to restrict themselves to a tiny subset to avoid the pain or they carefully curate a workflow that mostly does the job over the course of years.

Suddenly within a week of trying a new tool you just… don’t carry any of that any more.

It’s like going from GOTOs to structured programming with encapsulated functions. People made many useful programs with GOTO. Some people were more principled than others, but we all got by. But it turns out that functions and loops are a way better mental model for control flow than GOTO. Nobody had to switch and there were plenty of holdouts. But eventually the benefits were impossible to ignore.

People like Dijkstra evangelized structured programming because they “saw the light”.

Re: Jujutsu for busy devs

#423

Post by baq »

1718627440 wrote: post #387
baq wrote: post #376

Earlier quoted context omitted.

> You can use git commit --fixup to record what you want to change in an earlier commit. jj just does it correctly by default. > rerere jj just does it correctly by default. > As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto. jj just does it correctly by default. defaults matter.

>> git commit --fixup > jj just does it correctly by default. JJ adds changes to random old commits instead of the newest one? Yikes. > rerere by default Takes space and time. > --update-refs by default Maybe sensible, don't need it most of the time.

> JJ adds changes to random old commits instead of the newest one? Yikes.

jj adds changes to the current commit, which is the staging area, which is the index, which is the working copy. I get you don't like it, no need to be an ass about it, but denying that it works is just that, denial.

> > rerere by default

> Takes space and time.

doesn't take my time. I'll take it.

> > --update-refs by default

> Maybe sensible, don't need it most of the time.

No reason to waste time thinking when it's needed.

Re: Jujutsu for busy devs

#424

Post by andrewaylett »

esafak wrote: post #61
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…

Do you use an IDE with git support but not jujitsu? I do (intellij), and I'm not sure how useful it would be.

I use colocated mode, so Git tools see a detached HEAD but otherwise continue to work. I don't normally use the IDE for creating commits or moving around the repo, but I'll still use it for conflict resolution and for exploring history.

Re: Jujutsu for busy devs

#425

Post by alfiedotwtf »

skydhash wrote: post #291
jon-wood wrote: post #261

Earlier quoted context omitted.

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…

The UI may be cluncky in the PR page, but I just use rebase, edit the commits, and force push the whole branch. The PR is the unit from the business perspective, not from my computer environment. I don’t mind creating two PRs for stacked changes, then once the first is merged, rebase from the main branch and publish the second one. Comments can be used to explain the link.

I think the confusion and angst comes from when someone has multiple unrelated commits, submits it as a single PR, and is then REVIEWED intermingled all at the same time!

If people instead reviewed commit by commit until the PR HEAD, the code itself would tell a story, but best of all - the story would then be obvious!

Re: Jujutsu for busy devs

#426

Post by stouset »

renox wrote: post #298
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…

At work we 1) use a git hook to generate Gerrit IDs for new commit. AFAIK, JJ doesn't support these. 2) we also use submodules, which must be handled using git commands. So if I decide to use JJ, I'll have to use a mix of JJ and git..

For 1, gerrit and jj have recently collaborated to standardize on a commit footer where stable revision IDs are encoded in the jj style.

This landed in a jj release a few months back. I assume it’s live in gerrit now too.

Re: Jujutsu for busy devs

#427

Post by stouset »

exclipy wrote: post #224
Disposal8433 wrote: post #115

Earlier quoted context omitted.

I've always hated the git CLI, and that's why I used Jetbrains tools or Sublime Merge. Now that I switched to jj (colocated with a get repo, very useful), I went back to using the CLI again for jj and I don't miss the graphical tools.

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.

Re: Jujutsu for busy devs

#428

Post by stouset »

nchmy wrote: post #307
darthrupert wrote: post #203

Earlier quoted context omitted.

You can consider your perfect conversion rate now broken; I tried jujutsu on a personal project and found it to be a hassle without any upsides. I believe your perception is flawed because the people who just try it and throw it away don't tend to talk about it because it's not popular enough to warrant even a twitter comment. This is the first time I got the impulse to share this but only because you claimed a rathe…

Care to elaborate on the hassle and lack of upsides? Have you considered that you simply didn't give it a fair shake or were holding it wrong?

I don’t think this is a good approach toward getting people to switch. It’s unnecessarily combative.

Re: Jujutsu for busy devs

#429

Post by doritosfan84 »

nchmy wrote: post #187
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.

Here's a few great links that might be what you're looking for https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow

Ah I love that megamerge example. Thanks.

Re: Jujutsu for busy devs

#430

Post by palata »

gabrielgio wrote: post #409
palata wrote: post #353

Earlier quoted context omitted.

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

My initial rant to your comment was about this: > And I don't get why people keep trying to convince me that I do. It's about me, my opinion should have some value, right? :-) I have no problem whatsoever if you don't like jj or use git or whatever else you like. Let's paddle back: - you are in post about jj - you comment why you don't like jj - I comment why I like jj - you post that. Like, what is your intention he…

I didn't mean it to sound like this.

I have been asking a few questions, and I have received many answers quickly. Which is usually great, but between the "those who don't use jj haven't seen the light and must be in a cult" and the "jj is better because git is impossible to use everyday", it's honestly been harder than anticipated :-).

Post reply on HN