I mean sure Google & Apple are evil, but don't we all need some evil in our lives, EU citizens doesn't matter we love the evil and honestly we enjoy it.

What can't we do for these two companies we will beg, we will bend, we might even consider grovelling as long as the evil is around, to help us find the greater evils in the world. That is, the people we don't like, might be the bad guys today, but just don't worry you will be the bad guy too, just wait until the bad guys get into power...

I haven't read the hobbit or lord of the rings but man if this isn't greed corrupting all men then I don't know what is.

I feel sick of all this, I might really just move out and live the rest of my life out on the farm somewhere.

Fuck Github man, Fuck em'. I mean what even is the point. You lost the AI whatever it was, build a good product and features for developers like you tried to once.

And less social media shit, maybe adding better LFS alternative similar to huggingface and stuff.

Git isn't the popular choice in game dev because of this assets in tree hosting nonsense, why haven't we fixed it yet.

Similarly many edge cases, also finally they built stacked prs but man does it feel a under baked, and what it's like 2+ years late.

Please just improve Github, make me feel like I will be missing out if I am not on Github because of the features not because I have to be because of work.

Wow I randomly read, it is insane that, this isn't like hn frontpage. When random claude non vulnerabilities blogpost is...

We are definitely living in the worst timeline. Lmao

think of jj like,

I want to build xyz,

```

jj desc -m "feat: x y & z"

```

do the work.

```

jj split

```

Split up the parts and files that you want to be separate and name them.

This will also allow you to rename stuff.

```

jj bookmark create worklabel-1 -r rev1

jj bookmark create worklabel-2 -r rev2

# Push both commits

# since we just split them they are likely not inter-dependent

# so you can rebase them both to base

# assuming rev1 is already on top of base

jj rebase -s rev2 -d base

jj git push

```

That is it.

I am dumb. why is that better than a git branch or a git worktree ?

If you're already super comfortable in git, it's not. I'm saying this as someone who recently converted from git to jj and never wants to go back.

You also don't have to follow what the GP said. I never say `jj describe` before writing code. I write the code then just say `jj commit -m "Foo stuff"`, just like I would in git.

The bigger difference I've noticed is:

1. Switching between changesets just feels more natural than git ever did. If I just run `jj` it shows me my tree of commits (think of it like showing you git's branches + their commits), and if I want to edit the code in one of them I just say `jj edit xyz`, or if I want to create a new commit on top of another one and branch it off in a new direction, I just say `jj new xyz`. It took a little bit for my brain to "get" jj and how it works because I was so used to git's branches, but I'm really enjoying the mental model.

2. `jj undo`. This alone is enough to convert me. I screwed something up when trying to sync something and had a bunch of conflicts I really didn't want to resolve and I knew could have been avoided if I did things differently, but my screwup was several operations ago! So I ran `jj undo`. And ran it again. And again. And again. And then I was back to my clean state several stages ago before I screwed up, despite having made several changes and operations since then. With git? Yeah I could have gotten it fixed and gone back. But every time I've had to do something like that in git, I'm only 25% confident I'm doing it right and I'm not screwing things up further.

3. Rebasing. When I would try to sync git to an upstream GitHub repo that used rebasing for PRs, I would always get merge conflicts. This was because I stack my changes on top of each other, but only merge in one at a time. Resyncing means my PR got a new commit hash, even though none of the code changed, and now git couldn't figure out how to merge this new unknown commit with my tree, even though it was the same commit I had locally, just a different hash. With jj? I never get merge conflicts anymore from that.

Overall the developer experience is just more enjoyable for me. I can't say jj's flow is fundamentally and objectively better than git's flow with branches, but personally and subjectively, I like it better.

In sort of the same way juggling apples is better than juggling hand grenades: it's mostly the same in the simple cases, but once you start doing the really fancy stuff, one of the two will get you a lot fewer messy explosions.

(Your question is not dumb, BTW. The pithy answer is: UX matters, but it does so in ways that can be hard to convey since it's about the amount of cognition you need to put in a given thing to get a desired outcome, and that's tricky to express in text. Also there will always be some people for whom a new mental model just doesn't work. That doesn't make them dumb either, at least provided they have the wisdom not to petulantly piss in the cornflakes of those who get a kick out of how much better the new thing works for them.)

Thanks for the answer! To be honest, maybe because I've been using git for 16 years now, I find jj interface more confusing than git. All it takes to understand git, to me, is understanding the files and the operations.

There are annoying things for even experienced users like merging the history of merged repos, or sometimes patching a bisect for a bug.

Complex operations in git are complex and often there is nothing that makes them palatable enough to understand without really understanding git internal workings.

I will try once more when I feel my brain is more opened to the ideas jj is proposing. Thanks again

As a jj user, I would say I had the same experience for an entire year used it on and off, and then I just forced myself to use it, and it left a bad taste on the first week.

But on the second week I bungled a command that did some rebase and stuff and I paniced that I destroyed the work but alas it was all there.

I just hit jj undo and it all was there it snapshotted it all. I fell in love and just kept using it unafraid of making mistakes.

I think the worst part about git is being afraid to bungle up your work, jj makes obvious things obvious, asking someone in git land how to copy a commit as in duplicate it. And they might actually start crying even, if they have been using it for a while.

Generally you just create two branches but what if you want to copy and try to check which branch it would be easier to rebase on to, if you had to rebase.

This is not that hard if you have done it a couple times, but jj makes it so much easier, in big teams I feel like JJ is the only sane choice when git commands can get insane.

Also jj doesn't snapshot large files by default, aka, perfect no one mistakenly commiting a binary again. That is just unhinged when newbies do that and you need to flush that out of your git history.

Just the sane defaults + undo + obvious and simple commands was a huge sell for me and I grit my teeth and learnt it. And ofc in a jj git init repo you can always use git, best part often you can do all the simple operations in jj and then the hard one in git after creating a duplicate of the commit. To ensure nothing gets destroyed beyond recovery, further you can use jj state to recovery bad git state as well. It's all so nice that you will accept doing the harder stuff with git as well.

My pleasure! FWIW I used git for just as long as you, and after a few months with jj I feel more proficient with it than I ever was with git. Somehow it clicked in a way the git commands and options never quite did. But git is not going anywhere either way and is still a good tool, so if it works for you, when it comes down to it, that's the important part.

You have to put a lot of effort to mess up a git repo. So I'm not seeing the allusion to hand grenades.

I’ve done it multiple times without much effort. Or skill. Really it was a skill issue and I tried things that I thought would work but apparently don’t.

I screwed up jj a few times while picking it up, but jj’s undo command made that trivial to go back and try again. With git? I know a lot of things can be undone but I can never remember how to do it!

I'm glad to hear you never encountered the kind of quagmire that can occur around e.g. non-trivial conflicts while rebasing a chain of git commits. On large enough codebases, those can be common.

It's not, you can literally do everything this tool does with Git, and 80% of the features could be replaced with commands in your shell rc file also using vanilla git.

This tool was described perfectly the other day. JJ is the Dvorak of Git. Most people could careless about Dvorak layout, 99.8% of people use qwerty just fine. Those 0.02% though, they're loud, and they want everyone to know how great the reinvention of bread is.

Wtf is TBPN?

I personally find this is the correct solution, since indexes are over-inflated either way, this brings much needed sanity to the index. Your index is now worth much more or much less based on how you view the AI bubble and you are forced to understand and correct your forward looking investments accordingly.

Passive investments are good, but if taken too far as they clearly have been in the last decade they become a scam. Everyone is SIPing into it, and there is infinite liquidity. Until one big whale finally decides they are booking it, then all hell will break loose on the same damn day.

The issue is what each of the projects considers viable bug if you consider all localized assertion failures possible bugs then that's different from give me something that practically affects users.

Further browsers have a much larger surface area for even minor fuzzing bugs. Curl's much smaller surface area is already well fuzzed and tested.

Chrome has better fuzzing and tests too. Firefox has had fewer resources compared to Google ofc, so understable.

Ofc not saying it wasn't good. But given the LLM costs I find it hard believe it was worth it, compared to just better and more innovative fuzzing which would possibly scale better.

Into the Slopverse.