Earlier quoted context omitted.
A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language…
> - 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…
The creator of Jujutsu has joined ERSC
231–240 of 283 posts
Re: The creator of Jujutsu has joined ERSC
#232Earlier quoted context omitted.
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…
They're not experienced with git, but still use the command-line? Interesting. Or would you think a jj GUI would help them?
Re: The creator of Jujutsu has joined ERSC
#233Badass!!! Congrats. I love JJ’s mental model. Its so much less opionated and lets me do what I want. Want to make 5 versions of the same commit? Easy. Need to push out a change asap without having to pre create a branch, stash your changes, yadayada. Jj just adapts. Once you start thinking in jj it becomes frustrating having think back to use GitHub as a code repo.
> Want to make 5 versions of the same commit? Easy When do you need something like this?
Re: The creator of Jujutsu has joined ERSC
#234Earlier 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.
Re: The creator of Jujutsu has joined ERSC
#235I 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…
Re: The creator of Jujutsu has joined ERSC
#236Earlier quoted context omitted.
If the worst thing you can say about a git hosting provider is that the performance of their blog is worse than the performance of their git servers, I think they're probably doing an okay job.
> the worst thing you can say about a git hosting provider is that the performance of their blog is worse than the performance of their git servers No one has agreed to this premise. You have invented it out of nowhere.
Re: The creator of Jujutsu has joined ERSC
#237Earlier 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 (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does thing…
> 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…
Re: The creator of Jujutsu has joined ERSC
#238Earlier 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…
But the thing is, Jujutsu is under the Apache 2.0 license right now. You are within your rights to use Apache 2.0 in proprietary products. Literally anyone, at this exact moment, could clone the repo and integrate it into a proprietary product, or share proprietary binaries built on the code (rename it Gugutsu VCS) without giving up the source, as long as they obey the ASL 2.0 terms. The CLA really has nothing to do with this fact.
If you are personally worried about your personal copyrighted patches going into proprietary products -- or if that's your only worry -- you basically need to avoid contributing to all projects that are not using a copyleft license; just avoiding CLAs or whatever isn't enough. This has been true for a while.
If you are worried about a "rug pull" the next question is whether the developers can actually do that. That is a matter of social configuration of the project, not licenses. The thing with "rug pull OSS projects" is mostly about ownership and labor. Licenses and CLAs really don't matter much if 99.8% of development comes from one group of unified engineers. Such a setup is risky even with a 0% chance of any license changes. Their company might fail or they might all get fired. You didn't get rug pulled, but the project might die, which is basically just as bad.
But for Jujutsu, there is no majority of developers from any one company, and significant amount of code comes from the community, so the answer is more or less "no, we can't do that even if we wanted." The best we could do is start a whole fork and lose a significant chunk of the community and contributors. There isn't any one group of people with enough of an iron grip to do that without sustaining massive losses.
I think people sort of get "Can this become proprietary", with "Is some possible" -- in this case Jujutsu's code can absolutely "become" proprietary already in a real way. You can just go do that now. But a lot of "rug pull" things are prevented, I think, simply due to the fact we have a robust and strong community outside the (paid) developers
Ultimately, for a non-copyleft project, non-assigning CLAs like the one Jujutsu has are basically just annoying, legal ass covering mechanisms for Google's sake. I also do not like the CLA, it's just basically an irrelevant piece of paper as far as my principles on the matter are concerned. The Linux kernel DCO is basically just a CLA with fewer words, motivated by similar concerns to not get backstabbed due to the business logic of suing people.
If we got rid of the CLA for Jujutsu, I personally think it would probably still be nice to ask people to respect the DCO.
Re: The creator of Jujutsu has joined ERSC
#239Earlier 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.
git cherry-pick + git rebase -i (to swap commit order)?
?
Re: The creator of Jujutsu has joined ERSC
#240Earlier quoted context omitted.
> 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.
Now imagine having other branches starting from the commits that just got rebased, also including merge commits. jj handles that just as well.