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

501–510 of 552 posts

Re: Jujutsu for busy devs

#501

Post by KingMob »

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 like to phrase it as "jj enables everyone to be the git guru".

The git gurus responding how they can do X/Y/Z don't quite realize that git is still cumbersome enough that most people never bother to reach their level of proficiency.

Whereas jj is simpler, better-designed, and more powerful, so it's easier to start doing more advanced VC.

I also think everyone's underestimated how much universal undo enables exploration.

Re: Jujutsu for busy devs

#502

Post by KingMob »

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

You have a point, but it's more like it's difficult to articulate, than a cult.

I think of jj as the ultimate refinement of git. It's not revolutionary, in the sense that there's no must-have feature, but it's a distinct evolutionary upgrade that's just way more pleasant than git.

It's telling that most hard-core git gurus are lukewarm on jj at first, but for everyone else, jj makes it way easier to do guru-level version control.

Just my $.02, anyway.

Re: Jujutsu for busy devs

#503

Post by darthrupert »

nchmy wrote: post #471
stouset wrote: post #428

Earlier quoted context omitted.

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

Even though the parent comment was outrageously combative, you're probably right that it wasn't necessary to reply in a much milder, but similar fashion.

Perhaps you just didn't give my comment a fair shake and were reading it wrong.

But I don't think parent comment to mine was "outrageously combative", I just thought it was a bit silly to claim a 100% conversion rate.

Re: Jujutsu for busy devs

#504

Post by anticodon »

pclowes wrote: post #470
anticodon wrote: post #131

Earlier quoted context omitted.

I used bisect once in my life but it was extremely helpful. Without it I'd spend weeks trying to find regression. With bisect I found and fixed it in under 1 hour. It's a command that is needed rarely but there's no replacement for it in some situations.

I am confused by this, isn't Bisect just some git ergonomics with respect to flagging a checked out commit as a success failure and then checking out the next midway commit depending of if it was a success/failure to enable classic binary search? It might be slightly more tedious but couldn't you just do the same thing manually and it would add just a couple minutes to the search and you would still save weeks? I lik…

Agree, probably could be done in any other VCS as well, including CVS. But only possible if you actually use VCS and use it properly.

Re: Jujutsu for busy devs

#505

Post by normie3000 »

stouset wrote: post #404
UK-Al05 wrote: post #379

Earlier quoted context omitted.

Reviewers don't want to navigate 33 tiny PRS either. The best way of getting changes is through is simply sitting down and talking with the reviewer. Most of these small PRS, splitting things, creating elaborate stacking systems are just technology hacks around a social/process problem. I've seen people make more of a mess trying to split pr's up where they are so fine grained its silly and actually had dependencies…

> Reviewers don't want to navigate 33 tiny PRS either. As opposed to one 33-change PR? Yes, absolutely yes they do. I probably don’t have time to review a giant PR like that. If I do, I feel guilty asking for fixed in one part when 31 of the changes are great. Why are we holding up all these improvements for one or two small concerns? We can merge and just fix those later. Except that never happens. I probably have t…

> As opposed to one 33-change PR? Yes, absolutely yes they do.

100% this.

With remote teams spread across time zones, mega-PRs become even more problematic.

Re: Jujutsu for busy devs

#506

Post by 1718627440 »

steveklabnik wrote: post #466
1718627440 wrote: post #448

Earlier quoted context omitted.

You can have merge conflicts, when you combine two commits (--amend in git terminology, not sure how it's called in jj)?

Oh, since you said 'merge' I thought you meant like git merge. Amending a commit works the same way as git. The difference is just that the oplog will have the full history, including before you amended, so you can roll back easily.

So the history of the second commit gets discarded?

Re: Jujutsu for busy devs

#507

Post by 1718627440 »

BeetleB wrote: post #494
1718627440 wrote: post #185

Earlier quoted context omitted.

You can absolutely do that in git: git checkout master git rebase [whatever] [rebasing stuff] git tag rebasing git checkout --detach master [do random other stuff] git tag todo git checkout rebasing [continue rebasing] When you are not trying to modify the same branch you're rebasing, you can omit --detach and also git tag todo. (To clarify, it has never occurred to me that I even want to do that, so I didn't knew ho…

I know you're trying to point out how easy it is in git, and some months ago I would have agreed. But after using jj (for only a few weeks!), your commands seem needlessly complex. In jj, you run the rebase command. If you get conflicts, and want to switch to something else before you fix all of them, you simply do "jj edit" or "jj new" and work on something else. Then you do "jj edit" to go back to the conflicted re…

You don't need to tag, you also just specify the commit SHA, isn't that the same in jj? It's just convenience.

The difference here seams to be that in jj you're always in a commit while in git you're always outside. But that's the difference between one and two commands.

Tags are hardly a new concept, if anything they are easier then a rebase. You can't really expect to use something with knowing the core concepts. Thats true for every tool and also for software. Can you use jj without knowing what a commit is?

I didn't knew about --detach before. It was obvious from the error and easily found using autocomplete. Also you only need it, if you want to change something under yourself while you're already modifying it.

Re: Jujutsu for busy devs

#508

Post by 1718627440 »

sunshowers wrote: post #454
1718627440 wrote: post #185

Earlier quoted context omitted.

You can absolutely do that in git: git checkout master git rebase [whatever] [rebasing stuff] git tag rebasing git checkout --detach master [do random other stuff] git tag todo git checkout rebasing [continue rebasing] When you are not trying to modify the same branch you're rebasing, you can omit --detach and also git tag todo. (To clarify, it has never occurred to me that I even want to do that, so I didn't knew ho…

As far as I know you can't start another rebase -i while you're in this situation. But it's been almost two years since I last used rebase -i so I might be wrong.

Yes, that's because a rebase in git is nothing special, so you influence the rebase with normal git commands. When you do normal interaction like committing or resetting these become part of the rebase.

Re: Jujutsu for busy devs

#509

Post by globular-toast »

stouset wrote: post #130
globular-toast wrote: post #121

Earlier quoted context omitted.

I tried it and didn't switch. The funny thing is I immediately recognised that it was forcing me to use git in basically the same way I use it anyway. I have more than 15 years experience with git at this point. I never had to do the "delete repo and reclone" thing after the first year. In other words, I actually understand git, so I don't really need Jujutsu. I also already use very good tooling for git, namely Magi…

> In other words, I actually understand git, so I don't really need Jujutsu. This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj obsolete. I am (or was) a git expert. I’ve used it since pre-GitHub. I’ve written a git implementation. I know (or knew) the interface inside and out. I haven’t deleted and re-cloned a repo in as long as…

Thanks for the thoughtful reply. I can see how in fact jj could be considered an adjacent tool to Magit. Similarly Magit does not "dumb down" git like other git GUIs. As the Magit manual puts it, it's actually a fully fledged git porcelain. I guess jj is the same.

So I think I would revise my comment above and say I don't need jj because I've already got a toolkit that does a similar thing. I haven't raw dogged the git CLI in a decade.

However if I ever run into a problem like yours and my tools aren't cutting it I'll definitely keep jj in mind so thanks for showing me!

Re: Jujutsu for busy devs

#510

Post by MForster »

WhyNotHugo wrote: post #181

The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually cop…

> The main things that drives me crazy about jj is that all changes are always staged implicitly.

That's one way to look at it, but I would encourage you to think about it a bit differently.

JJ does not have a concept of "staging", it only has changes and commits. Yes, it automatically snapshots the workspace commit, but I wouldn't use the workspace commit as your staging area. If you want to do explicit staging use the parent commit (@-) as your staging area. You can move changes from the workspace commit (@) to the staging area (@-) explicitly, just like in Git. And you can "commit" (Git terminology) your staging area by starting a new staging area.

The difference here really is "only" that the workspace, the index, and committed changes are modeled with the same concept. And that is very powerful. Admittedly you have to make an informed decision on how to map your workflows onto the model, but that is what comes with the powerful flexibility that it gives you.

Post reply on HN