Live data from Hacker News

The creator of Jujutsu has joined ERSC

ersc.io

271–280 of 283 posts

Re: The creator of Jujutsu has joined ERSC

#271
post #245

Earlier quoted context omitted.

Because Martin was the lead maintainer and original author and worked at Google for over a decade until like a month ago, and so as a project it fell under their typical standards in the Google OSPO department and had a CLA applied. When it moved orgs, they had to own the org too, so they could keep CLA robot in. That's basically it. It's just a really successful project that has grown far beyond one company or perso…

I'm trying to come from a place of help, truly, so bear with me. You have to get out from under Google. This would be a red flag during due diligence for many investors. I'm not saying Google is going to fuck you over but why not just get yourself into a place where you don't need to be writing replies like this, and we don't need to be having this conversation. And also, I would strongly recommend acquiring trademar…

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.

Re: The creator of Jujutsu has joined ERSC

#272

Earlier quoted context omitted.

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.

Who is the assignee in the CLA? It is not obvious to me.

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

Re: The creator of Jujutsu has joined ERSC

#273
post #12

Someone will have to explain the value proposition to me... We have git. jujutsu works with git. git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git). Thus, jujutsu is a UX / new steering wheel. ERSC is trying to be a GitHub competitor with what surplus value? Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the down…

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site. While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not po…

Since enterprises are your target audience, how are you planning on tackling CI? How easy would it be to use Nix in there?

Re: The creator of Jujutsu has joined ERSC

#274

Earlier quoted context omitted.

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site. While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not po…

Since enterprises are your target audience, how are you planning on tackling CI? How easy would it be to use Nix in there?

Have a look at https://nix-ci.com Nix and CI are a match made in heaven :)

Re: The creator of Jujutsu has joined ERSC

#275

Earlier quoted context omitted.

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site. While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not po…

Since enterprises are your target audience, how are you planning on tackling CI? How easy would it be to use Nix in there?

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.

Re: The creator of Jujutsu has joined ERSC

#276
post #187

Earlier quoted context omitted.

As a Mercurial fanboy, git took off thanks to being from Linus, and a requirement to contribute to the Linux kernel, from there the adoption wind was in motion.

As an ex BitKeeper fanboy with a history all the way to RCS, Git was just better.

Better than Bitkeeper maybe.

I also have used plenty of SCM systems since mid-90's.

Re: The creator of Jujutsu has joined ERSC

#277
post #98

Earlier quoted context omitted.

It is possible to move one step further: use own store, speak git protocol. In the end, it is about the commit-tree-blob model. I think, the main headwind is the broad decay of interest in computer science topics. Where can I read on jj merge resolution strategies? LLM links to Arch Linux man page and other random stuff.

Using a different data store breaks compatibility and dramatically increases the friction to switching to it. jj's superpower is that my usage of it is invisible. Right now I'm working on Github projects in jj where none of the other contributors are. Nothing about my usage of jj requires them to change anything they do. The jj tutorial is useful: https://docs.jj-vcs.dev/latest/tutorial/

https://github.com/jj-vcs/jj/tree/main/docs/technical

Re: The creator of Jujutsu has joined ERSC

#278
post #251

I pretty much only use jj now, and it was really good even just with the CLI. But adding jjui changed the story entirely. I now rarely use jj without just booting up jjui first. It will be good to see what jj will look like with more funded dev work, but I'm always a little worried about financial incentives mixing with the tools I use for the long term. I guess the saving grace is that I don't really need more upgra…

Same here. I keep jjui open the whole day, rarely reaching for jj itself. It really changed the way I work with repos.

This is the way

Re: The creator of Jujutsu has joined ERSC

#279

Earlier quoted context omitted.

> I did not like it at all. Because it left you fewer opportunities to experience the ecstasy of typing git commands into a terminal? Or because it didn't work so well?

Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later. I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.

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.

Re: The creator of Jujutsu has joined ERSC

#280

Earlier quoted context omitted.

Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later. I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.

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.

The absence of "needing to manage the index" is what breaks my workflow.
Post reply on HN