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

291–300 of 552 posts

Re: Jujutsu for busy devs

#291

Post by skydhash »

jon-wood wrote: post #261
RUnconcerned wrote: post #222

Earlier quoted context omitted.

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…

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.

Re: Jujutsu for busy devs

#292

Post by killerstorm »

tomasyany wrote: post #266

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features.

A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.

Re: Jujutsu for busy devs

#293

Post by nchmy »

stavros wrote: post #268
palata wrote: post #254

Earlier quoted context omitted.

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…

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing thing…

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

Re: Jujutsu for busy devs

#294

Post by nchmy »

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?

Forget between team members - it's an issue just for my own local dev purposes, when I'm working on multiple changes/PRs at the same time and want to test them all out before they get merged to main in the origin.

Re: Jujutsu for busy devs

#295

Post by riwsky »

ben0x539 wrote: post #275
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'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…

Mental model: “everything is a commit”. Commits are commits. Stashes are commits. The working tree is a commit. The index doesn’t exist, because it’s unnecessary.

The data model is technically of revisions, which are stable across operations like rebases (which change the underlying git commit).

How to conceptualize a branch: as a bookmark of a specific commit.

Re: Jujutsu for busy devs

#296

Post by nchmy »

esperent wrote: post #112
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…

> there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. This sounds exactly like something a person evangelizing it would say.

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

The evangelizing for these things comes because these tools start to heal the trauma that came from immense friction. We want others to be similarly liberated.

For those who say "I don't feel friction/trauma with git, legacy Python tooling etc", I can only say that you're living in Plato's cave/the matrix/in a cult/with Stockholm syndrome and just don't know what you're missing out on.

Re: Jujutsu for busy devs

#297

Post by gabrielgio »

palata wrote: post #251
gabrielgio wrote: post #216

Earlier quoted context omitted.

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

> 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

You are in *forum* in a post *about jj* saying there is no reason to use jj. We are just interacting as you'd expect in forum. If you don't see any reason to use anything else and don't want to hear anything about it steer away from these posts.

No one is trying to convince you personally, we are just discussing the tool. Go use git and be happy.

I sincerely won't read anything else past that line.

Re: Jujutsu for busy devs

#298

Post by renox »

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

Re: Jujutsu for busy devs

#299

Post by notmywalrus »

1718627440 wrote: post #248
nchmy wrote: 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?

I would call `jj absorb` a new feature (new if coming from git, I believe the idea was taken from hg). It moves diffs into the closest ancestor that touched those files/lines. Very useful for addressing reviews, then just `jj absorb` and watch them get squashed into the correct location.

This gets even better with octopus merges (known in the jj community as "megamerges"): open up 5 branches at the same time, address minor tweaks in any number of them, and `jj absorb` the content into the right parent branch.

Re: Jujutsu for busy devs

#300

Post by nchmy »

mcepl wrote: post #274
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…

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.

Git infrastructure works just fine with jj...

And there's nothing crippled about thr git repos.

Try jjui for a great TUI experience on top of jj.

Post reply on HN