Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switch to Jujutsu Already: A Tutorial

stavros.io

Post reply on HN
Print view View original

51–60 of 164 posts

Re: Switch to Jujutsu Already: A Tutorial

#51

Post by mpalmer »

packetlost wrote: post #36
jakebasile wrote: post #8

I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code b…

The best thing that could come out of jujitsu is git itself adopting the change-id system (which I believe I read somewhere is being considered). If you actually take time to learn your tools and how they're intended to be used, there's really not reason to learn jj IMO

git is both a (bad) UI and a protocol. Jujutsu is a UI on top of git (the protocol).

There's nothing wrong with taking the time to learn how to use a bad UI, especially if there's no other option. But don't mistake your personal mastery of git for evidence that it's better than jj.

In all likelihood, the git proposal you allude to would not extend further than adding a bit of persistent metadata that follows commits after "destructive" changes. And even then, it'd be imperatively backing into the change-as-commit-graph data model rather than coming by it honestly.

> If you actually take time to learn your tools and how they're intended to be used, there's really not reason to learn jj IMO

This is like saying if people take the time to learn curl, there's really no reason to learn Firefox.

And it doesn't suggest to me that you're all that familiar with jj!

- automatic rebasing! goodbye to N+1 rebases forever

- first-class conflict resolution that doesn't force you to stop the world and fix

- the revset/template languages: incredibly expressive; nothing like it in git

- undo literally any jj action; restore the repo to any previous state. try that with the reflog...

No amount of learning git nets you any of these things.

Re: Switch to Jujutsu Already: A Tutorial

#52

Post by ahartmetz »

palata wrote: post #2

I have been trying Jujutsu for a few weeks. It's cool and I like trying new things. I wouldn't say that it's so much better than git, though; there is nothing that I miss in the projects where I use git. On the other hand, I have issues with Jujutsu, one of which completely prevents me from using it in some projects: * No support for git submodules. One can dislike submodules as much as they want, if I need to contri…

I also have that problem with submodules. Of course they are crap, but the project uses them.

Re: Switch to Jujutsu Already: A Tutorial

#53

Post by tcoff91 »

jakebasile wrote: post #8

I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code b…

Heres a great article about a powerful workflow that jj makes practical https://ofcr.se/jujutsu-merge-workflow/

Where jj shines is advanced workflows that aren’t practical with git. If you aren’t interested in those then it doesn’t give you as many benefits over git.

If you are breaking down your features into small PRs, stacking them, etc…, then jj is super helpful.

Re: Switch to Jujutsu Already: A Tutorial

#55

Post by ljm »

itchynosedev wrote: post #4

I really loved jujutsu for the few weeks that I used it. However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git. In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.

One of the bigger selling points of JJ just wouldn't work so well without larger team buy in for me: the ability to push stacked PRs.

I like the idea of it, but there's so much inertia around typical git workflows that revolve around the GH pull request model (with the only difference being the use of trunk based dev or some git-flow like branching strategy) that it'd be hard to change without a lot of buy in.

I still think back to Phabricator and its approach to code review, noting that it sadly never got wider traction despite having notable benefits over a completely entrenched status quo.

Re: Switch to Jujutsu Already: A Tutorial

#56

Post by ahartmetz »

drdrey wrote: post #26

it's hard to take the article seriously when the author relies on a fuckgit alias on a regular basis

git rebase|cherry-pick|revert --abort and git reflog can solve pretty much all of my problems with git repos in weird states, and any advanced Git user should know them.

Re: Switch to Jujutsu Already: A Tutorial

#57

Post by bdangubic »

manbash wrote: post #22

Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The…

It's not that it is superior, it is completely inferior to git :) That is why you are failing to see :)

Re: Switch to Jujutsu Already: A Tutorial

#58

Post by Izkata »

et1337 wrote: post #42
umvi wrote: post #30

I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article. Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph. If you use this menta…

I think the author is one of those folks who were able to fully grasp the beauty of the Git data model for the first time by switching to Jujutsu. It makes it easier to see the “DAG of commits” vision than Git with its index and stashes and confusingly named commands with fifty flags.

Which is why I always make sure to show that graph to co-workers new to git (we have a lot of code still on svn):

  git log --graph --oneline --decorate --all -100
I keep it as an alias, but it is annoying that seeing the whole structure is so hidden away.

Re: Switch to Jujutsu Already: A Tutorial

#59

Post by nchmy »

oxceedo wrote: post #40

In the past 2 months, I saw 3 articles about JJ. Always the same starting point: "I don't understand how git works". If you can't understand git, one of the most used tool in the whole industry, this is a *you* problem. You MUST take the time to understand how it works properly. Every job you'll get and every projects you'll work on will use a Version Control (at least I hope). Abstracting this knowledge by using a t…

Are you writing everything in assembly? If not, your argument has no legs.

Moreover, you can use jj almost completely seamlessly with a git repo - including PRs etc to github. I do it daily and no one is the wiser.

Re: Switch to Jujutsu Already: A Tutorial

#60

Post by tharkun__ »

stavros wrote: post #38
tharkun__ wrote: post #37

Earlier quoted context omitted.

SVN was not fine. Branching took forever (all the copying). And the space that required ... In fact, lots of things took forever on large-ish repos. Remember that everything required the server and network and disk speeds were slower back then. And just a commit could destroy your work if you got stuck in a conflict resolution. So you'd have to copy all the files you changed to a backup just in case, then delete them…

Well you can either have a viewpoint of "the current thing I use is fine because I'm used to the warts" or "it's not fine because other things exist". It can't be that SVN is bad and git is better but also that git is fine even though jj is better.

Except that it has to first be true that jj is better ;)

You start out the article with hate for git without explaining what you actually don't like, then here on HN say "I don't hate git". A command called `fuckgit`? Because you need to re-clone? What are the things you commonly do that require this? I've never encountered it. Maybe you're just too advanced a user for git and jj really is better for you. But for us lowly regular users I really do not see an issue.

Some of the benefits you tout, like "editing a commit and you don't need to commit it yourself"? I'm sorry but I want to be the one in control here. I am the one that says "I'm done here, yes this is the new version of the commit I'm comfortable with". I've specifically forbid Claude to add, commit, push etc. for example.

It also breaks your "you need to stash" argument. I don't stash. I just commit if I have something WIP that needs saving while I work on some other emergency. There's no reason not to just commit. In fact I do that all the time to checkpoint work and I amend commits all the time. It's my standard commit command actually `git commit -a --amend`.

Automatic "oplog" of everything Claude did, IDE style: sure, maybe. Though I've yet to see that need arise in practice. Just because I have Claude et. al. now, I don't believe changes should be any bigger than they used to. Nor should my "commit early, commit often, push later" practice change.

Post reply on HN