Live data from Hacker News

The creator of Jujutsu has joined ERSC

ersc.io

211–220 of 283 posts

Re: The creator of Jujutsu has joined ERSC

#211

Earlier quoted context omitted.

Wasn't it partially owned by Google? Or are they just a contributer now?

I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license. That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is somethin…

How is it under its own org, but changing the CLA is up to Google? Google must therefore administer the separate org?

I get why you may want to color this as non-Google-owned but it seems to very much still be Google-owned.

Re: The creator of Jujutsu has joined ERSC

#212

Earlier quoted context omitted.

Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general

Do you have a public example of an open source project that you are using that showcases those features? In your opinion, is jj losing steam? How do you feel about it requiring a CLA to contribute to, which would enable the developers to go closed-source and keep all the contributions of the community? Are you afraid of vendor lock-in?

> a public example of an open source project that you are using that showcases those features?

IMO that's almost fundamentally impossible. The whole point is that it makes maintaining a "clean" linear commit history easier than git, so by the time you push anything the observable differences are already gone. At best you just see a repo without any WIP-style commits, which can be done using more effort and git alone.

Re: The creator of Jujutsu has joined ERSC

#213

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…

Yes, really. You just proved the other poster’s point. He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset. Git is quite powerful, but the cli is a train wreck of complexity and inconsistency. Learning the options to one git command means you’ve learned the options to exactly one git command. No other git comma…

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset

You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version control can help in the software development process.

It wasn’t until I got involved into OSS that I learned more which in turns give me the motivation to use and learn about git in depth. I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.

Re: The creator of Jujutsu has joined ERSC

#214
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…

IMO JJ allows a simpler "mental model" than git.

Git is a DAG of commits, each of which is a node in the DAG. There's also a staging area that isn't a node in the DAG, and a working copy that also isn't a node in the DAG. The head nodes of every branch in the DAG are always named in git, and every node in the DAG also has a description. Nodes are immutable, but the edges between nodes are mutable so you can edit a node by replacing it with a new node & updating the edges.

JJ is a DAG of commits. Each commit is a node. Nodes have stable identifiers, automatically generated. Nodes may have descriptions. Nodes may also have names (bookmarks) which get used for compatibility with git's branch names. Nodes are mutable, but by default nodes pushed to a remote will be immutable.

Re: The creator of Jujutsu has joined ERSC

#215
post #203
post #199

Earlier quoted context omitted.

As someone who was a mercurial fanboy too, critical element was that Github happpened for git while mercurial had nothing comparable - and before anyone points at bitbucket, it fucking sucked in UX

Yet UX wasn't a problem for Git adoption.

It was huge problem for Git adoption, that's why I mentioned GitHub

EDIT: GitHub had probably the first UX where I actually liked what I got, compared to various earlier git based ones, or the horrible CVS and SVN ones where clicking on a file name definitely didn't do what you expected.

I barely remember Bitbucket from the mercurial era but I do recall that while it was better than some, it was still worse than GitHub, whose "here's default branch's HEAD, plus auto-opened and formatted README" was really a game changer

Re: The creator of Jujutsu has joined ERSC

#216

Earlier quoted context omitted.

I honestly kind of think your experience is in favor of the GP’s assessment.

Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.

[deleted]

Re: The creator of Jujutsu has joined ERSC

#218

Earlier quoted context omitted.

Thanks! I don't have Opera installed on my Win11 machine, but I tried it in Edge and it's barely using anything, but I realize that I have something beefier than a shared GPU on it. I've filed a bug internally and we'll make sure to take a look. We don't use these animations in the product, only the company site, so this is the first time it's hitting a broader audience. I appreciate the report and sorry about that!

Firefox on win11 here, scrolling the page is super choppy and it pegs my GPU at 100%.

Pushed a fix, let me know if it hasn't improved for you.

Re: The creator of Jujutsu has joined ERSC

#219

Earlier quoted context omitted.

I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.

What if I _want_ a staging area?

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

Re: The creator of Jujutsu has joined ERSC

#220

Earlier quoted context omitted.

It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.

that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management. I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon f…

The ability to rebase, reorder, and squash like this only really makes sense with jj’s autorebasing IMO.

With git, if you do this, everything after is left orphaned. Even if you have a GUI that does this for you, now rebase conflicts become an enormous pain.

Post reply on HN