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

271–280 of 336 posts

Re: I see a future in jj

#271

Post by steveklabnik »

coastalpuma wrote: post #238
baq wrote: post #24

I’m just sad pijul doesn’t get the same attention or love from the community. It desperately needs an ability to colocate with git.

Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.

I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.

Re: I see a future in jj

#272

Post by steveklabnik »

zZorgz wrote: post #168
steveklabnik wrote: post #163

Earlier quoted context omitted.

Yeah, in that case you may want to configure bookmarks to auto update for sure :)

Is there a way to do that today? For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices). It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.

Yes, it's called "experimental-advance-branches" (because it landed before the branch -> bookmark rename). Here's an example of setting it:

https://github.com/jj-vcs/jj/blob/c70f9b5b3fff08a86fb11afc57...

Re: I see a future in jj

#273

Post by SAI_Peregrinus »

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?

The same way Git ensures that no two repos generate the same commit ID: by using a cryptographic hash function.

Re: I see a future in jj

#274

Post by mpalmer »

CuriouslyC wrote: post #265
mpalmer wrote: post #254

Earlier quoted context omitted.

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

if I make a plan which causes the project to be identical to its state 5 years ago, the edit distance is zero, but in no way can you call that a measure of history

Re: I see a future in jj

#275

Post by baq »

steveklabnik wrote: post #271
coastalpuma wrote: post #238

Earlier quoted context omitted.

Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.

I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.

I think git compat is the absolute #1 priority for working devs to even consider seriously checking version control tools out. I wouldn’t have tried jj if I couldn’t run it on my work git repo and I didn’t try pijul on my work repo for this reason. It hurts my inner geek who’d like to try using it for something professionally.

Re: I see a future in jj

#276

Post by baq »

Hendrikto wrote: post #233
baq wrote: post #189

Earlier quoted context omitted.

In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.

> Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change. Does not sound any easier or more intuitive than git.

The only intuitive user interface is the nipple.

It isn’t how git porcelain wants you to work, but it does make sense once you stop thinking in git. Working copy being a first class commit unlocks all the dag manipulation tools without stashing, having to resolve conflicts in middle of tricky operations, etc. ‘Easier’ is exactly the point, but it’s about workflows which are very inconvenient in git like rebasing stacked PRs.

Re: I see a future in jj

#277

Post by baq »

1718627440 wrote: post #211
aardvark179 wrote: post #175

Earlier quoted context omitted.

Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.

And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?

It isn’t that it doesn’t support it, it kinda does, but the recommended workflow is such that the index is simply pointless.

Re: I see a future in jj

#278

Post by jasonpeacock »

tom_ wrote: post #140
jasonpeacock wrote: post #107

Earlier quoted context omitted.

Perforce’s binary support is basically equivalent to Git LFS, it does the same thing. What does Perforce binary support have that Git LFS doesn’t? AFAIK, the base issue that Perforce is already in use and it has enterprise support.

1. Perforce checkout requests always do the round trip to the server. 2. Artists can actually understand Perforce.

> Perforce checkout requests always do the round trip to the server

That's literally the antithesis of Git. If that's a requirement, then yeah - Git's the wrong thing.

It's like complaining that bicycles don't have motors like motorcycles. If it had a motor, it wouldn't be a bicycle.

Re: I see a future in jj

#279

Post by jasonpeacock »

dijit wrote: post #176
jasonpeacock wrote: post #160

Earlier quoted context omitted.

From the user's perspective, when setup correctly Git LFS is transparent and they don't see the text pointers - the binary files are replaced on push and pull to the server. It's the same user experience as Perforce? Yes, Git is more low-level and it's possible to see those text pointers if you want to.

This is what you want to believe but its not true. I’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers. It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone afte…

Not a belief, but my experience. Maybe I've had a blessed experience with LFS? It's always "just worked" for me.

Re: I see a future in jj

#280

Post by nonethewiser »

baq wrote: post #50
nonethewiser wrote: post #31

Earlier quoted context omitted.

can you directly get the parent branch of a branch in jj? This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."

I don’t think you ever need to do this, jj tracks changes much better than git, assuming I understand your question. E.g. you can rebase a whole local change dag based on a commit from origin with a single jj rebase -b and it’ll move bookmarks (git branches) correctly.

Thanks stack overflow
Post reply on HN