Live data from Hacker News

The creator of Jujutsu has joined ERSC

ersc.io

171–180 of 282 posts

Re: The creator of Jujutsu has joined ERSC

#171

Earlier quoted context omitted.

It's in the post, but Martin will be continuing to work on jj itself as well as on our products, just as he did at Google, working on the open source jj but also their internal source control team. As a side note, jj has rules around company representation in maintainership, and so when this initially happened a few months back, ERSC actually became over-represented in the maintainers group, as we also employ several…

That idea about keeping maintainer balance is pretty neat, interesting to see this kind of diligence in maintainership in the same project where legal ownership belongs to a single company, Google, via the Contributor License Agreement. My interest in jj cooled off a lot after seeing that, even though I realize in practice it's pretty unlikely to be of consequence - I just don't need even that kind of low probability…

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.

Re: The creator of Jujutsu has joined ERSC

#172
post #57

Working with Martin has been a real pleasure, and we'll have some more stuff to talk about very soon!

Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.

many developers have not learned git in depth

They have less to walk away from then.

Re: The creator of Jujutsu has joined ERSC

#173
post #133

Earlier quoted context omitted.

It's hard to tell since any given dev can just use jj locally, if they want to, while everyone else uses git.

Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)

Huh, fortunate for it that GitHub (especially) preserves it then!

I wonder how guaranteed that is, can imagine GH deciding to 'clean' it (how much data can you put there theoretically? Or to close a range of potential security issues) and suddenly relatively niche but genuine uses like jj's change-id are unintentionally not preserved.

Re: The creator of Jujutsu has joined ERSC

#174
post #170

Earlier quoted context omitted.

> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started u…

But what if you didn’t have to read a 400-page book to properly version control your software?

"Properly" is doing a lot of work here (Claude would say it's load-bearing ;) If one's needs are modest, then no, the 4-5 basic operations don't need a 400-page book to understand, and are quite proper for version-controlling one's software.

Re: The creator of Jujutsu has joined ERSC

#175
post #173
post #133

Earlier quoted context omitted.

Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)

Huh, fortunate for it that GitHub (especially) preserves it then! I wonder how guaranteed that is, can imagine GH deciding to 'clean' it (how much data can you put there theoretically? Or to close a range of potential security issues) and suddenly relatively niche but genuine uses like jj's change-id are unintentionally not preserved.

Cleaning it would change the commit ID, so a forge cannot clean it even if it wanted to (not without rewriting all descendant commits too and breaking signed commits, at least).

The change-id is exactly as much part of the commit object as the author/committer name/timestamp, description, parent commit ID, tree, and participates in the commit hashing as those do.

Re: The creator of Jujutsu has joined ERSC

#176
post #143
post #142

I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whe…

I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-id…

IIUC, "@--+::" should read "all descendants of the children of the grandparents of the current commit".

Or if it were a family tree, "all descendants of your parents and their cousins" (ignoring that family trees are way more constrained than DAGs).

I have no idea why you would use that revset; I assumed it was just an example of revset's complexity and power.

As a pragmatic matter, unless I'm scripting with revsets, I personally stick to a few go-to aliases.

Re: The creator of Jujutsu has joined ERSC

#177
post #143
post #142

I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whe…

I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-id…

isn't that what protected branches etc are supposed to fix in platforms like GitLab/GitHub/etc? My team has yet to break any important branches
Post reply on HN