Live data from Hacker News

The creator of Jujutsu has joined ERSC

ersc.io

221–230 of 283 posts

Re: The creator of Jujutsu has joined ERSC

#221

Earlier quoted context omitted.

Who says it's too complex to have multiple implementations? It's under an open source license notably unlike BitKeeper, what's the problem?

> There is a mandatory CLA you must agree to. Importantly, it does not transfer copyright ownership to Google or anyone else; it simply gives us the right to safely redistribute and use your changes. [Emphasis from the source] Does this make it possible for the jj organization to make the implementation closed-source and proprietary, and abandon the open source version, taking all the contributed changes from volunte…

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

Re: The creator of Jujutsu has joined ERSC

#222

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?

I loved the staging area in git. That was the biggest thing that held me back from adopting jj for a long time, thinking it was a huge step backwards.

It wasn’t. I was wrong.

The staging area is just a commit like any other, only due to git’s design it has to be special-cased everywhere. In jj it’s just a commit.

I do all my work on an unnamed commit on the tip of a branch. As I complete bits, I extract out cohesive sets of changes into new commits (split) or as patches of earlier commits (squash).

Re: The creator of Jujutsu has joined ERSC

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

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

Re: The creator of Jujutsu has joined ERSC

#224

Earlier quoted context omitted.

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…

Would the CLA makes it easier to move away from Google and transfer the ownership to a new organization (if Google is willing)?

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.

Re: The creator of Jujutsu has joined ERSC

#225

Earlier quoted context omitted.

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.

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.

Re: The creator of Jujutsu has joined ERSC

#227

Earlier quoted context omitted.

> - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase Can you explain this to me? I feel like Git is pretty easy there. - select oldest commit to modify - move the commits around with a mouse or the cursor - close the editor to apply Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me. Alternatively I can…

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.

> I don’t like to think about how I’d do that with git.

   git -c sequence.editor="sed -i '1ip oldercommit'" rebase -i @~
Git using standard UNIX tools for these things instead of a specialized syntax, means I can easily write more complicated automations.

Re: The creator of Jujutsu has joined ERSC

#228

[dead]

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.

Re: The creator of Jujutsu has joined ERSC

#229

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.

> I don’t like to think about how I’d do that with git. git -c sequence.editor="sed -i '1ip oldercommit'" rebase -i @~ Git using standard UNIX tools for these things instead of a specialized syntax, means I can easily write more complicated automations.

It's great to use what you prefer, but I don't think most people would see that and think "ooh, convenient!"

Re: The creator of Jujutsu has joined ERSC

#230

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…

I also used to use a GUI (https://gitup.co/) for that reason, and jj has completely replaced it for me.
Post reply on HN