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

101–110 of 552 posts

Re: Jujutsu for busy devs

#101

Post by noroot »

_bent wrote: post #12

I've been using jj for two weeks now and it's kinda exciting, because for the first time I'm comfortable with using version control just via the command line. With Git I always had to use a GUI (preferably Git Graph in VSCode) and launch all operations by right clicking items, but jj was simple and consistent enough that I could just start using it after reading Steve Klabniks tutorial. The thing I'm running into rig…

I'm in a very similar situation: been using git for a long time, but anything more complicated always via some kind of UI (often intellij).

Been using jj without significant issues for about a month and been super happy to be comfortable using the cli and slowly ramping up to more complicated operations.

The documentation still assumes a lot of inherent knowledge which sometimes makes it a little difficult. I love seeing blog posts like these and hopefully some more in depth resources will appear over time. Steve's guide is good, but there are still gaps for me :).

Next I want to learn some more revset language and become a bit more fluent with rebase operations. I love the more simplified cli, conflict resolution and op log!

Re: Jujutsu for busy devs

#102

Post by 000ooo000 »

do_not_redeem wrote: post #7
Lyngbakr wrote: post #5

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that cha…

If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.

FWIW, @ is a shortcut for HEAD in Git.

Re: Jujutsu for busy devs

#103

Post by viraptor »

ants_everywhere wrote: post #65
Filligree wrote: post #54

Earlier quoted context omitted.

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great.…

Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. 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…

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

You're thinking in very git-specific terms. JJ is just different in many ways so such comparison doesn't work well. I didn't get it from explanations before, but trying it in practice, it's a non-issue. It may be easier to just give it a go.

Re: Jujutsu for busy devs

#104

Post by wredcoll »

ants_everywhere wrote: post #65
Filligree wrote: post #54

Earlier quoted context omitted.

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great.…

Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. 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…

> 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

Since you brought this up, I've noticed some people seem to work this way but I've never found anyone to ask why they do this.

I get the idea behind clean, readable git logs with nice consistent messages, but isn't that what rebase/amend is for?

To me, the status of my local git log is mostly irrelevant, the thing that really matters is the commit(s) I submit for merging.

Also, probably for related reasons, I've never truly understood why git has this whole separate staging concept...

Re: Jujutsu for busy devs

#107

Post by wredcoll »

steveklabnik wrote: post #70
ants_everywhere wrote: post #49

I'm confused what this is? Is it just a git frontend for people who are confused by git? It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Some of the design decisions are also not great. Working copy as commit means you have no quality control. T…

> I'm confused what this is? jj is a version control system. It is backend-agnostic. The most common backend is a git one, because git is so popular. This allows you to use jj on a git repository, allowing for individuals to adopt it without forcing their teammates to. > Is it just a git frontend for people who are confused by git? I used git since before github existed. I considered myself a git lover before I found…

I want to appreciate this cool-sounding new tool, but everything you've said sounds exactly the same as using git rebase, what am I missing?

Re: Jujutsu for busy devs

#108

Post by resonious »

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 used jj for several months, then eventually went back to git.

The biggest killer was performance. jj operations took several seconds for me, whereas git is instantaneous no matter how big the project. Maybe this is fixed now.

But also honestly I felt like there was a bit more mental burden to using jj. When I switched back to git, it was like a weight off my shoulders. Maybe that's just due to the decade of constant use though.

Re: Jujutsu for busy devs

#109

Post by wredcoll »

packetlost wrote: post #51
plandis wrote: post #43

Earlier quoted context omitted.

As far as I know, by default Git doesn’t enable the “reuse recorded resolution” feature so if you made a change to the first commit you’d have to manually do the same thing for any subsequent commits.

If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).

What is the "right" way to do it then?

Also probably most of us are stuck with whatever git*.com supports anyways...

Re: Jujutsu for busy devs

#110

Post by npinsker »

resonious wrote: post #108
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 used jj for several months, then eventually went back to git. The biggest killer was performance. jj operations took several seconds for me, whereas git is instantaneous no matter how big the project. Maybe this is fixed now. But also honestly I felt like there was a bit more mental burden to using jj. When I switched back to git, it was like a weight off my shoulders. Maybe that's just due to the decade of constan…

I used to have the same problem (on Windows only, not Mac) but it seems to have been fixed as of a month or two ago.
Post reply on HN