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

481–490 of 552 posts

Re: Jujutsu for busy devs

#481

Post by 0x457 »

1718627440 wrote: post #452
0x457 wrote: post #444

Earlier quoted context omitted.

May I use how often and why you use bisect? I don't remember the last time I needed bisect. Well, I also don't work in linux kernel sized repos, so there is that.

> May I use Was that 'may I ask'? Not that often, but not seldom. Its useful if you have a bug, that isn't obvious where it comes from, but easily testable. Then you just write a test and let git figure out where it comes from. The test doesn't need to be automatable. I also used it for firmware that needs to be flashed and the bug effected in an LED blinking incorrectly. I still saved a lot of time.

> Was that 'may I ask'?

Yes, can't type sometimes.

I see. Maybe it's just what kinda of code and/or how I write it, usually pretty clear which abstraction isn't doing its thing. From there, it's either clear what is the bug, or git blame will reveal what changed.

This has a much higher chance of succeeding if you maintain strict boundaries and isolation which isn't always possible.

Re: Jujutsu for busy devs

#482

Post by ephimetheus »

So far whenever jujutsu came up I didn’t find its features that convincing relative to git.

I have to say however that the mega merge workflow seems intriguing and might in fact be a solution to having to serialize my work like I do in git for now.

I think I’ll look into that.

Re: Jujutsu for busy devs

#483

Post by Ralith »

1718627440 wrote: post #433
dubi_steinkek wrote: post #344

Earlier quoted context omitted.

I don't think that's a fair characterization. It's more that there isn't really a big difference between the workflow of # you're on staging area @ commit A # make some untracked changes and console logs you don't wanna commit git add -p && git commit # select only what you want vs # you're on @ empty commit | commit A # make some local changes (which are tracked in @) jj commit -i # select only what you want You're…

Wait, what happens when there is a multi-GB file laying around and a jj command is being invoked? Does it start to scan it or is there some threshold. What does it do with cyclic hard-/sym-links?

There's a (configurable, easily bypassed) limit for newly created file size to catch that common mistake.

Re: Jujutsu for busy devs

#484

Post by joshka »

turboponyy wrote: post #197
stouset wrote: post #133

Earlier quoted context omitted.

The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a staging area with jj! I would surmise most jj users do too. It's just a real, honest-to-god commit in the repo instead of a special snowflake. # do some work … # prepare a new, empty commit if…

Can you edit commits by adding on only parts of your "staging" area? Because that's my workflow. I produce a few focused and semantically coherent commits that I'd like to apply to the codebase, where each keeps the codebase in a working state. I might be working on more than one thing at once, but I know which commit each set of changes should "live in." An append-only log of commits is decidedly not something I wan…

jj squash allows you to move changes from a revision to another. Default is your working copy, but there's nothing preventing you from working on several semantic commits and moving changes from your working copy to those commits as you want.

    jj squash --into -r
Where is @-, a change id, or perhaps a bookmark name if you want to give a semantic name to your changes.

Re: Jujutsu for busy devs

#485

Post by nswest23 »

palata wrote: post #143
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…

> 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 do you know? Maybe jj would be a productivity improvement for you. Maybe it wouldn't. There's only one way to find out and it seems like a pretty painless thing to try. If this is your attitude toward new things do you still pump water out of a well when you're thirsty?

Re: Jujutsu for busy devs

#486

Post by BeetleB »

mpyne wrote: post #392
steveklabnik wrote: post #386

Earlier quoted context omitted.

jj tends to use -i for 'interactive' to do what you do with -p in most git commands. It is in fact a great tool, jj makes doing this even easier.

I'm sure it's great but I don't have the problems with git that others apparently do, so as to make it worth switching to a whole new mental mode of source code management. At least uv solved real problems I was having with Python package management, but for my own personal usage git is 99% aligned with what I need.

Just FYI: The person you're responding to wrote a very popular tutorial on jj. He's been using git since the early days, and as he puts it:

> Now I am not one of those "the git CLI is too complex and git is too hard to learn" people, but I do acknowledge that puts me in the minority. But let's reframe that: if we can make something more powerful and easier? Sign me up!

Re: Jujutsu for busy devs

#487

Post by BeetleB »

sethammons wrote: post #168
stouset wrote: post #154

Earlier quoted context omitted.

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…

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

This is the one thing I always point to when I say "Mercurial is better" (and now, jj).

Why can't we have our cake and eat it? Mercurial lets you have lots of individual commits, but they're hidden, and you'll see only the squashed commit. Why do we have to lose all those individual commits to get that squashed commit? The answer: You don't need to.

Re: Jujutsu for busy devs

#488

Post by BeetleB »

DrBazza wrote: post #323
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…

>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. Agreed. Having used SCCS, CVS, Subversion, VSS, Perforce, Clearcase, Accurev (the weirdest of the lot), Mercurial and Git, I'll move when the market decides what has critical mass and my job needs it. jj feels a bit like learning a Dvorak keyboard and then being in an office of qwerty. Jobs wa…

> Jobs want git, my colleagues know git

And outside of a few scenarios, they can use git, you can use jj, and everyone will be happy.

I push to my team's Git repo using jj all the time.

Re: Jujutsu for busy devs

#489

Post by BeetleB »

palata wrote: post #254
IshKebab wrote: post #215

Earlier quoted context omitted.

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…

Ha! Good example!

Once I started using jj, I realized how poor/annoying git's stash is. You don't need a concept called stash in jj. You have some work done and want to stash it? Just leave it alone as a leaf node (or split your commit into a leaf node). Then branch off the parent to work on whatever you want.

And with jj, my "stashed" node is version controlled in itself. I can make changes to it, undo it, all while still being stashed. (Maybe you can do this in git - I don't know).

Other niceties of jj:

Why do I need to come up with a commit message only when committing? Why couple the two? With jj, you can just decide to work on X, write your commit message "Adding cat photos to Easter Egg", and then work on the feature. Or you can just start working, and in the middle of it all, add the commit message, and continue working. You can change the commit message at any point.

Why do I need to fix merge conflicts immediately? Just the other day in jj, I made a change, which resulted in a merge conflict in several nodes. Whatever - I just branched off a clean node and worked on what I needed to. Only the following day did I go and fix the merge conflict.

Why can I only merge two branches? And why do I need to think of from/to when merging? A merge is basically creating a new node that is the child of multiple nodes. It's symmetric - there's no from/to. And you should be able to specify 10 parents if you want to.

Re: Jujutsu for busy devs

#490

Post by BeetleB »

Zambyte wrote: post #354
stavros wrote: post #268

Earlier quoted context omitted.

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…

> because there's no single thing that you can do with jj that you can't with git. - jj undo, jj op restore, and jj --at-op to reset or view the repo at a previous state - create multiple directories (workspaces) backed by a single repository at different commits These are the only things I can think of off the top of my head that you can do with jj that you can't do with git.

> jj undo

Yeah - the other day I did a fetch, and then decided I didn't want to fetch. I simply ran "jj undo" to undo the fetch.

Post reply on HN