steveklabnik

> the other extreme

These aren't the only two options.

This

> Pip installs everything system wide

does not inherently mean

> you can't have different versions of the same package

Because it became a meme virtually everyone who says this are actually joking and not serious.

They'll move on to whatever the next meme is.

Sort of but also no. Intrusive lists are not likely to ever be possible in safe code, almost by definition.

What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index".

I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it.

(I never set autosquash either)

It is absolutely possible, but all of the data we currently have shows that reducing the amount of code that could possibly have the error has meaningful effects on the number of vulnerabilities. Mitigation may not be the same as elimination, but it is effective.

Not directly relevant.

We are also sort of at a "bespoke factory" stage where building a factory means doing it around your specific codebase, each of which has their own needs and quirks. Just taking one of these wholesale from one company and using it at another would not work.

We'll see if in the future, as people begin software projects this way, if there is more standardization. I suspect that there's just too much going on too fast at the moment to do it any other way, a decent factory for Opus 4.8 looks very different than one good for Astra, I'd guess. And models are just one axis.

writing prose and writing code are two different things

I can get good code out of LLMs. I can rarely get good writing out of them.

Maybe it's a skill issue, but it's not inherently a contradiction that they're better at some things than others. It's much easier to RL coding than writing.

I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.

We plan on building everything as individual building blocks, that you can use or not use as you wish.

Initially we won't be offering our own CI directly, you'll bring your own. We use Buildkite internally, so we'll probably share that integration first, but fundamentally you can do whatever you'd like. We won't require you to use whatever first-party offering we end up with.

You give Google the right to take your patch and use it under any license. There is no assignee because there is no reassignment.

(Also, as I just said in another comment, I forgot about trademark: if the community did want to fork, they'd have to rename.)

Since I posted previously, I realized I had forgotten trademark entirely, and Google does own the trademark for jj. (See my other comments about the Mozilla/Rust connection, it was the same back then too).

It's not an issue for investors, because again, Google does not own this, and we aren't even modifying jj at this point, and are unlikely to need to. The IP is very clear and not an issue.

> There's nothing starting me from creating jjhub.com tomorrow and that is a real potential threat for you.

That's fine! There's a lot of people already doing this, today. Competition is natural.

Because jj is backend agnostic, you can use it with whatever VCS you'd like. git is very common. So it has the exact same amount of "lockin" as git does.

If there's interest in alternative implementations, then they'll happen, simple as that. The reason it hasn't happened is that there isn't any desire for one.

No clue, I’ve never heard of that. What does it tell you?

I don’t actually know who owns the org offhand.

My point is not that it is “not Google owned” but to point out the specifics, which really matter. “Google owned” to me implies that they own the copyright to contributions, which they very much do not. That doesn’t mean that they have no control over it at all, of course, but the specific details matter a lot.

Doesn’t really change it at all. Because there’s no copyright assignment, it’s not any different than any other open source project that doesn’t do it, there’s no ownership to actually move. It would just be about socially what is considered upstream.

Various git commands can drop the metadata, so it’s not guaranteed to stick around.

It gives Google the ability to use the source code under whatever terms they want. It does not change the Apache licensed code at all, which can still always be used under that license.

There is no “the jj organization”.

It’s a usage pattern, not a feature. It’s a really common way of working with jj: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

Legal ownership does not belong to a single company. All copyrights are still held by each individual contributor, and they're available to be used under the Apache 2 license.

The CLA means Google also has a license to the code to do what they will with it, but it does not do copyright assignment. They do not own your contributions.

Oops you’re not wrong, there’s just a lot of comments and it’s hard to keep threads straight, my bad :)

We’ll find out!

Thanks man :)

While this is true and I agree with you, to be clear we do way more than just a nice UX. There is a lot of deep technical work going on here. If anything the UX isn’t the selling point, we are an infrastructure company at heart.

Yes. Stacked diffs are table stakes.

Yes, he joined a few months ago, this is just getting it onto the site :)

We tested it in mobile, but several people pointed out that we have more performance work to do to make sure that the animation is fast on lower-end hardware. I don't know what phone you're using, but we'll get it fixed regardless.

While this is true, we do care about performance tremendously, and the animation not having good performance cuts against that, so I think it's a very fair criticism. Paying attention to details matters.

Thanks!

Yes, it's important to realize that git is multiple things: the on-disk repo format, the CLI, and the wire protocol. Each has their own challenges, just like any project, but they can be tackled independently. But at the end of the day, there just are fundamental limits to the way that git does things that make total sense in the context Linus developed git for, but just do not in other ones. Some of those are performance related, but some of those are things like how the kernel is an open source project, and so per-directory ACLs are something that git wouldn't ever bother supporting, but are valuable for companies. We'll be talking about these things in the future, so I'm just going to be hand-wavy about it right now. But we do think that git is a really great system that has served us all well for 20 years, but just like how git displaced systems before it due to significantly re-thinking the details, for some users, making meaningful improvements over git will also require a similar significant re-think. That's just the way of technological development.

I joined ERSC ten months ago!

The things I am most interested in right now are jj and llms. And the intersection between the two. I'm thinking a lot these days about how agentic development is changing our industry, with source control being one part of that.