Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I see a future in jj

steveklabnik.com

Post reply on HN
Print view View original

261–270 of 336 posts

Re: I see a future in jj

#261

Post by jtwaleson »

mpalmer wrote: post #252
jtwaleson wrote: post #245

Earlier quoted context omitted.

I see what you mean, and having looked a bit more deeply today, it's clear that jj is very compatible. However, my point is that having two ways of doing this within a team is already confusing. What if one person writes a "this is how we work" document on the wiki and mentions some git, and the next person rewrites it to jj? It's extra things to think about. It's like supporting developers from a team with both Wind…

If a team has members who unilaterally rewrite best practice docs to include their preferred technologies, the fault is not with the tech.

I didn't pick a great example and didn't explain it eloquently, but I hope you understand my point. Supporting multiple ways of working takes effort.

Re: I see a future in jj

#262

Post by CuriouslyC »

Gormo wrote: post #260
CuriouslyC wrote: post #248

Earlier quoted context omitted.

Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail. The next generation of VCS should be atomic, with a proper database tracki…

> Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, Is this an oblique way of saying that Git should not be replaced?

No, but the lift of replacing git is huge, so we shouldn't do it for a Python2->Python3 sitaution, we should have a replacement that really brings big wins.

Re: I see a future in jj

#263

Post by jtwaleson »

mpalmer wrote: post #253
jtwaleson wrote: post #209

Earlier quoted context omitted.

If a product is 10x better than what's currently available, it will see rapid adoption. There was obviously something about git that made it MUCH better than the precursors and that's why it obliterated everything else. I highly doubt that new tools will be 10x better than git. Maybe 20%?

You should really try it; it's clear you're learning some things about it just from this thread. Will a product that is 10x better see rapid adoption if people who have not used it still choose to criticize it in the abstract?

I'm happy to give it a try when I have some time, but I have 0 problems with git right now so it's not top of my list. My critique is also really not towards jj specifically, I'm just discussing the idea that git has extremely wide adoption now and that this has benefits :)

Re: I see a future in jj

#264

Post by baq »

cryptonector wrote: post #256
oefrha wrote: post #130

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For pe…

> Plus I rebase a lot Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.

This does not compute, like at all. jj rebase is half the reason to use it at all. Everything git does with the commit dag, jj does the same at worst, sometimes better.

It actually sounds like you're confusing jj with something else.

Re: I see a future in jj

#265

Post by CuriouslyC »

mpalmer wrote: post #254
CuriouslyC wrote: post #248

Earlier quoted context omitted.

Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail. The next generation of VCS should be atomic, with a proper database tracki…

I have no idea what problem this is supposed to solve. Where is the V in VCS here? How do you track the provenance/history of changes? You may not be "forcing" developers to "screw with a graph" (what?) but you are forcing them to screw with macros (we're adding a built-in scripting layer to the VCS?) and these unfamiliar new concepts called atoms and plans . > A VCS built around these principles would eliminate bran…

If you have a database of atoms and plans, the V is a row in a plan table, and you reconstruct history using plan edit distance, which is more robust than manually assigned provenance anyhow (it will retain some history for cherry picked changes, for instance).

I'm sure there would be new issues, but I think they'd be at the management/ops level rather than the individual dev level, which is a win since you can concentrate specialization and let your average devs have better DX.

Is it a weird use case? Imagine you refactor some code, but then you realize that a function was being called in a slightly incorrect way after a change (prior to the refactor so the revert isn't trivial) and you have to go back and revert that change, let's say over 100 files to be fun, and let's say that the code isn't perfectly identical. With git you probably have to do surgery to create a patch, with an atomic system you can easily macro this change, or you could even expose a UI to browse different revisions of a piece of code cleanly (which would blow up with git).

Re: I see a future in jj

#266

Post by steveklabnik »

cryptonector wrote: post #256
oefrha wrote: post #130

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For pe…

> Plus I rebase a lot Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.

I’m curious to hear more about what you find opinionated, I think one struggle I’ve had teaching jj to people is that it’s extremely flexible.

Re: I see a future in jj

#267

Post by steveklabnik »

Vinnl wrote: post #199

@Steve: Do you think it would be possible to expose ERSC's Bluesky account to the Fediverse? It's fairly straightforward via https://fed.brid.gy . Edit: Ah in fact, just like your personal account already is, so you know how straightforward it is :)

I’ll take a look at doing that once I actually start work :) I agree it’s something we should do.

Re: I see a future in jj

#268

Post by steveklabnik »

1718627440 wrote: post #217
KingMob wrote: post #194

Earlier quoted context omitted.

There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult…

> There's no need for staging or stashes in jj. What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this,…

So this is as an opinion I had when I heard about jj too. But the thing is, jj supports this workflow very well, and in fact better than git, because the stash/index is just a normal commit, not a separate feature.

In fact, the most popular jj workflow is closer to the git add -p workflow than it is git commit -a. I’d argue more jj developers work this way than git developers do in git, even.

Re: I see a future in jj

#269

Post by steveklabnik »

1718627440 wrote: post #227
pm215 wrote: post #224

Earlier quoted context omitted.

I would love the git index to not be a thing you had to care about unless you deliberately wanted to use that feature, but in my experience this is not the case...it feels to me like an implementation detail that surfaces into the UI more than it ought to.

But that is the thing, it is not exposed as an implementation detail, it is a skipable part of the user model.

It’s not really skippable because you have to know about it in order to skip it. And a lot of commands interact with it, and so it adds complexity to those commands, git reset being the most obvious case. But even stuff like rebase. Lots of commands that need to abort on a dirty working tree just simply work in jj.

Re: I see a future in jj

#270

Post by steveklabnik »

1718627440 wrote: post #216
KingMob wrote: post #194

Earlier quoted context omitted.

There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult…

How does JJ ensure that there are now change ID conflicts on push, i.e. so that no two repos generate the same change-id?

Until recently, change ids were entirely local (in the git backend). So conflicts just can’t happen.

Recently jj started including the change id in a header in the git object, so the receiving side can choose to respect/expose them as appropriate. An issue with this is that some git commands don’t guarantee the preservation of headers, so it’s possible to accidentally lose them; git rebase being a prime example.

Post reply on HN