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

251–260 of 552 posts

Re: Jujutsu for busy devs

#251

Post by palata »

gabrielgio wrote: post #216
palata wrote: post #149

Earlier quoted context omitted.

I do understand that point, but to me it sounds like "you should use jj because it's a lot better at solving problems you don't have". If there are really common use-cases where git is annoying and jj is great, it shouldn't be that hard to explain, should it? If you can say "remember how in the last few days you struggled with this? Jujutsu solves it", then I'm happy to try. If your argument starts with "imagine you…

> "you should use jj because it's a lot better at solving problems you don't have" It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve" > it shouldn't be that hard to explain, should it? It is not. There are plenty of example on this page. For me the biggest one is stacked PR, jj makes it trivial since it tracks the change sets and not commit ids (whic…

> It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve"

I don't have a lot of problems with git that I need to solve, that's the thing. 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? :-)

> It is not. There are plenty of example on this page.

The problem is that many examples, to me, sound like it's exactly like git but the author of the example doesn't know how to do it in git. For instance, you wrote a whole paragraph about "undo", as if git did not have that feature. Isn't that exactly `git reflog`? Turns out I had a need for it 2 times in the last 10 years, and it just worked.

> Simpler mental model for local change, no git stash/add necessary.

I can deal with git stash/add without feeling like I'm thinking hard. This is a class of examples that makes me think that jj is for people who are not comfortable with git.

It feels like the people who use jj tend to somehow get stuck on detached head with git, and that's a big problem for them.

Again, I'm not saying that jj is not cool, and probably I should try it. But I see a ton of comments that really, really sound like "I can't believe people still do basic arithmetic in their head: they should get a calculator and they would see how superior it is. With a calculator, you never make those frequent and annoying mistakes like 3+5=9 again! Plus you can do 403985/13 easily!". And when I say "I usually deal with basic arithmetic that I do just fine in my head, and I don't actually frequently make mistakes like 3+5=9", I feel like I sound like an elitist.

I can't remember the last time I had to do something "hard" in git. So it sounds like jj may make something simple slightly simpler, at the cost of dealing with a new tool.

Re: Jujutsu for busy devs

#252

Post by KingMob »

1718627440 wrote: post #189
steveklabnik wrote: post #82

Earlier quoted context omitted.

Kinda! jj has two kinds of these logs: the evolog and the op log. The git reflog is based on, well, refs. Whenever a ref is updated, you get an entry. This log is per ref. That's HEAD, your branches, your tags, and your stash. jj's evolog is sorta similar, but also different: it's a log, but per change (think commit in git). This means it is broader than per ref, as it includes not just commits that correspond to a r…

Yeah this doesn't make sense in git terms. A commit is immutable, it never changes so it doesn't have a history, it's just always there.

That's still true in jj, too.

But instead of commits, most of the time you're working with (the not greatly-named) "changes", which are a conceptual history of related commits. E.g., a single change ID points to the most recent commit in a list.

As long as you keep editing on a change, it keeps accumulating commits under the hood. When you move to another change (via `jj commit`, `jj new`, etc), all your new commits end up under a different change.

Re: Jujutsu for busy devs

#253

Post by baq »

1718627440 wrote: post #246
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'.

I'm not sure if objects won't get pushed accidentally. I would place the boundary at object creation not upload. Also you might copy the repo, then you also might leak an accidentally created object.

to each their own. you can argue in theory, in practice it is just not a problem.

Re: Jujutsu for busy devs

#254

Post by palata »

IshKebab wrote: post #215
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…

It's totally possible to have no issues with Git, e.g. if you are only using it for small or slow moving repos. There definitely are lots of big issues with Git though. I dunno how many jj solves but it doesn't seem unreasonable to suggest people move to a better system.

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 wrong with me?

Re: Jujutsu for busy devs

#255

Post by pinoy420 »

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…

[dead]

Re: Jujutsu for busy devs

#256

Post by palata »

whatagreatboy wrote: post #240
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…

How much time do you spend resolving merge conflicts between multiple team members?

In good approximation, I would say around 0 minute a week. I guess it could happen that it takes a few minutes, but I don't remember last time it happened.

Re: Jujutsu for busy devs

#257

Post by ants_everywhere »

baq wrote: post #238
1718627440 wrote: post #232

Earlier quoted context omitted.

Right now I can mess around like I want, because I am in charge what gets tracked, I need to specify it explicitly. This would loose that.

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.

Re: Jujutsu for busy devs

#258

Post by ceedan »

normie3000 wrote: post #173
sethammons wrote: post #168

Earlier quoted context omitted.

Nice commits can really tell a development story that makes reviews easier. That said, I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release. A very, very large problem at five out of six companies I have worked at is casual code improvement and refactoring. Devs would say, "we will ad…

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

Re: Jujutsu for busy devs

#259

Post by Filligree »

1718627440 wrote: post #172
wredcoll wrote: post #104

Earlier quoted context omitted.

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

I also work this way. A commit is really about, well, committing that these are exactly the right lines of code I intended to write. I also read them in another program, so it gets easier to not think that I already know the code and skip over. I basically start from the clean state (no changes) again and approve the changes line-by-line according to whether they fit the domain model of the program, whether they are…

By default, the top (current) commit acts like a staging area and in fact is implemented as a dirty working tree in git.

Commits start live without a description, and can’t be pushed without adding one. jj commit names the current commit and creates a new empty, unnamed commit on top, which effectively is precisely git’s behaviour.

I implore you to try it. In practice the distinction just doesn’t matter, except it’s one less concept to keep track of, and jj allows you to make up other workflows if you want.

Re: Jujutsu for busy devs

#260

Post by stavros »

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…

Can you go into some detail on how you do this? I use jj but it sounds like you make a change and then split it up into more changes after the fact, which I'm not familiar with yet.
Post reply on HN