Live data from Hacker News

Jujutsu for busy devs

maddie.wtf

271–280 of 552 posts

Re: Jujutsu for busy devs

#271

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!

It's because what you see as the inferior approach involves less effort and friction for the developers. When you are told to separate general code improvements to another PR, or worse, to not do them, and create a Jira task for them so they can be adequately prioritized, it just saps your will to do so. You just won't do any improvements that fall outside the scope of the feature, because even just thinking about th…

> It's because what you see as the inferior approach involves less effort and friction for the developers.

I can see that.

From the other side of the PR though, it involves significantly _more_ work from a reviewer.

The "red tape" of separating commits and opening separate PRs should be removed by the team.

The effort of separating commits and opening separate PRs is minimal once you're comfortable with the tools.

I encourage colleagues to be comfortable with these workflows, because a reviewer's time is generally no less valuable than their's.

Re: Jujutsu for busy devs

#272
post #242

Earlier quoted context omitted.

The commit message is the least useful part of all of this. It is just SO EASY to move, merge, split, rebase, squash etc commits, and even just individual lines and sections from within commits (via split). And it's all even easier via jjui I don't think there's anything any of us can really say to convince those of you who are constitutionally skeptical about it (or even allergic to it) why you should try it... If a…

It's just that I'm fine and also the features seam to amount only to a change in usage not in actual new features. In this case if you want to use commits instead of a stash, then you can do that just fine in git. It's also that I want my commit hashes to be stable (because I cross-reference them) and it sounds like they wouldn't in jj, because it is kind of rebase-y?

It's the new workflows that it enables via making existing features vastly more accessible (though there are some new features, such as merge conflicts not being a showstopper).

The only thing left for me to say to folks like you who think git is just fine (or even great) is that you're in Plato's Cave. https://en.m.wikipedia.org/wiki/Allegory_of_the_cave

You just don't know what you're missing out on. But if you give it a fair shake, you'll see the light quite quickly.

Take care!

Re: Jujutsu for busy devs

#273

Earlier quoted context omitted.

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…

Sure, sometimes I want to work with a WIP commit and then I'm just doing that in git.

I think functionally of the stage is about the UI, so keeping it separate is kind of the point. I find that useful, as I can use both approaches, not sure how its better if jj can just use one?

> to ask why they do this.

This was what I was trying to explain. To me the feature is needing to manually mark every line to be committed. If I need to split the commit I'm already not paying that much attention.

Re: Jujutsu for busy devs

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

yes, I haven’t managed for a week, but I tried to Jujutsu and gave up. It is too complicated for no visible gain. Plus, there is no infrastructure supporting it (in the end, you store the stuff in the crippled git repositories). `git commit --amend` and `git rebase --update-refs` together with few scripts (e.g., https://git.sr.ht/~mcepl/git-fixup) does the same, and I am still with true git.

Re: Jujutsu for busy devs

#275
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'm sure if I did the proper time investment I would enjoy jj. I've heard basically only good things about it in casual conversation. So far, my experience has been that I tried it, immediately got really annoyed that it automatically adds every untracked file that's not gitignored to the current commit, and was advised that I might want to stay with git if that's a problem.

That said, I struggle a bit with learning version control systems (that aren't git, like, I never really wrapped my head around svn or darcs or anything until they invented git). Seems like everybody just wants to write about the cool new commands they can run now instead of conveying how the data model works, or what mental model it wants to encourage. I had the same issue trying to get into pijul a while back, couldn't understand how to conceptualize the current state of a branch if I couldn't point at a commit in a tree and say "that's the branch, right there".

Re: Jujutsu for busy devs

#276
post #174

Earlier quoted context omitted.

> This is kind of a poor take. Why? They’re sharing what they prefer in response to someone claiming that everyone who tries the other thing comes to prefer that. They’re offering a reply in context and not in the slightest saying everyone should follow what they do. > By all means use what you prefer! That’s exactly what they’re doing. > But understanding git and knowing the "right" way to use it doesn't make jj obs…

"In other words, I actually understand git, so I don't really need Jujutsu." sounds like jj is for people who don't understand git. That's naturally a contentious statement. It implies that jj doesn't offer anything to experts, which seems easy to contradict given how many people with git expertise will talk about getting value from jj. At worst, it could be taken as a bad faith kinda put-down, like, suggesting at jj…

Alright, that’s fair, I can indeed see that reading.

Re: Jujutsu for busy devs

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

[deleted]

Re: Jujutsu for busy devs

#278
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 it for several days and went back to git; it doesn't really provide that much for someone already proficient with git, and you need to know the underlying mechanism well for when something goes wrong anyway (just like with any other abstraction).

Re: Jujutsu for busy devs

#279
post #242

Earlier quoted context omitted.

The commit message is the least useful part of all of this. It is just SO EASY to move, merge, split, rebase, squash etc commits, and even just individual lines and sections from within commits (via split). And it's all even easier via jjui I don't think there's anything any of us can really say to convince those of you who are constitutionally skeptical about it (or even allergic to it) why you should try it... If a…

It's just that I'm fine and also the features seam to amount only to a change in usage not in actual new features. In this case if you want to use commits instead of a stash, then you can do that just fine in git. It's also that I want my commit hashes to be stable (because I cross-reference them) and it sounds like they wouldn't in jj, because it is kind of rebase-y?

Commits in jj have both a commit has (which is unstable) and a commit id (which is not).

Generally you use the id, not the hash.

And yes, everything you can do with jj you can also do with git. It’s just that most people don’t, because it’s much harder with git, involves rebases and changing hashes, and so on.

Re: Jujutsu for busy devs

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

There's also subcamps.

Those who have tried it and

1) actually gave it a fair shake - and are now evangelize it, and

2) people who simply didn't give it a fair shake due to a) time restraints and b) just not having an open enough mind to genuinely try it out

And then those who haven't tried it but

1) have never heard of it, and

2) are unwilling to try it because they are stuck in their ways (I view these people as being in Plato's Cave, or the matrix, or a cult - even though us evangelizers obviously sound like we're in a cult). They're in an even sadder position than those who tried it half-heartedly.

All such sorts of people are on display in this thread. I hope us zealots have been able to convince (hopefully via education) at least a few to try it out.

And also to try jjui, which is incredible.

https://github.com/idursun/jjui

Post reply on HN