10 ms·
jj init – getting serious about replacing Git with Jujutsu
- MattPalmer1086 3y agoIronically, it says that the problem with git is you have to internalise it's model to use it effectively. But then describes JJ in terms of how it relates to what git does. Talks about how it uses revisions not commits or something, but never really explains why it's good, just more that it's different to git. So I think this is probably a very good article for someone who actually knows git, but isn't very good for the users he says would most benefit from it!
- johnea 3y agoWhat a waste of time. GIT works fine! This is a solution in search of a problem. Detached HEAD and all, it's not that complicated to use. When you come up with a replacement for javascript, then I'll be interestted...
- segfaltnh 3y agoWhat a waste of time. JAVASCRIPT works fine! This is a solution in search of a problem.
- deleted 3y ago[deleted]
- steveklabnik 3y agoI keep hearing things about jj being excellent, but haven't actually tried it. My brain is very git wired at this point, but when you keep hearing good things...
- heyoni 3y agoI have to say, I really like that it claims to work in an async fashion with rsync/dropbox not interfering with the repo. But my brain is also wired hard on top of git.
- chriskrycho 3y agoThe first couple weeks there was definitely some friction, especially because having the working copy be a commit itself takes some real getting used to. Once I got over that and learned that I did not need to name every branch and could just work away and name branches only for pushing to Git remotes, the switch flipped very hard the other way. Git feels awful now.
- agumonkey 3y agoI'm still in the first stage, it's already very strange to see how such a simple change (working copy being a commit) can trip your brain.
- deleted 3y ago[deleted]
- Arnavion 3y agoI'm surprised to see an alternative git frontend that doesn't immediately drop the index for being "too complicated", which in turn makes me drop the alternative git frontend for being "too simplistic". I might try this one out.
- rqtwteye 3y agoI think the index is one of the best features of git if you work with a git GUI.
- morsch 3y agoIt's great even if you don't
- notso411 3y ago[dead]
- ilyagr 3y agoThe article makes a similar point. In theory, this is not an advantage of the idea of the index, but simply a consequence of the fact that no GUIs have yet been written with jj in mind. In practice, this can be a real limitation of jj for people who are used to such GUIs, for now.
- charcircuit 3y agojj did drop the index. What appeal do you see in git's index? All it's ever done for me is slow me down by needing to do extra commands / arguments which I sometimes forget.
- Arnavion 3y agoBased on the description in the article, it does the equivalent of `git add`ing every change by default, but allows you to choose a subset of those changes to be in the actual commit. So the net effect is the same as if nothing was `git add`ed by default and I ran `git add -p` to choose the subset of changes to be in the actual commit, which is what I use the index for.
- ayberk 3y agoI hope they change the binary name since "jj" is a common <ESC> binding for vim users :)
- vitiral 3y agoAre you using vim to run shell commands?
- PufPufPuf 3y agoIn what context would that collide?
- ftigis 3y agoneovim and vim (since v8.1) come with a terminal mode, and the default key combinations to get out of terminal mode is a little cumbersome (<C-\><C-n>). It's not unthinkable that if someone already maps jj to get out insert mode that they would do the same for terminal mode.
- vulcan01 3y agoA shell alias can fix this.
- allan_s 3y agoYou just type it slowly so that the waiting time for command expires
- forrestthewoods 3y agoNow it just needs a VFS so it can seamlessly work with large binary files. Maybe it has some support for this already since it apparently works with Google’s internal monorepo? I can’t tell what the story there is.
- crotchfire 3y agoWake me when they upstream it. I can't afford to invest in Google's soon-to-be-abandonware projects.
- charcircuit 3y agoJujutsu is not a Google product. Jujutsu is not a fork of anything, so upstreaming it does not make sense. It does support git repos, but that is a mandatory feature for new version control software to compete with git as people don't want a VCS that is not compatible with one's existing repos. It doesn't mean it's a fork of git.
- crotchfire 3y agoIt's a downstream consumer of (lib)git.
- Zambyte 3y agoIt looks to me like they just use libgit as a dependency. Do they have a fork of libgit that they would push changes upstream from?
- crotchfire 3y agoYou seem really fixated on this "fork" thing, which is not mentioned anywhere in my comments.
- Zambyte 3y ago> Wake me when they upstream it. Where is upstream?
- deleted 3y ago[deleted]
- resonious 3y ago
- foxes 3y ago[flagged]
- mgaudet 3y agoI stumbled a bit using jj on a big repo [1], but I too am very interested in seeing it grow and evolve. I plan to return to my experiment sometime, would love tips on large repos and making it more manageable. [1]: https://www.mgaudet.ca/technical/2023/11/23/exploring-jujitsu-jj https://www.mgaudet.ca/technical/2023/11/23/exploring-jujits...
- ilyagr 3y agoFor speed on large repos, you can try using `watchman`. It's briefly documented at https://martinvonz.github.io/jj/latest/config/#filesystem-monitor https://martinvonz.github.io/jj/latest/config/#filesystem-mo....
- bvrmn 3y agoComplains about Git's tag/branches difference is a high chance author left Mercurial boat before they made proper branches. BTW jj's documentation does a better job explaining what's the revs and changes are. My only grudge with jj's CLI it uses `-r` to specify first class entities. Git here does rare proper thing and uses positional args for commits and ranges.
- barlog 3y ago呪術
- andrscyv 3y agoI don't mean to be mean, but it takes too long to get to the point:(
- barlog 3y ago呪術 (Jujutsu) the name is! Jujutsu is a very meaningful and good name for VCS.
- degurechaff 3y agoprediction: someone will create GUI for jujutsu with name "kaisen"
- barlog 3y agoSorry The correct way to read it seems to be Jujutsu (柔術), not Jujutsu (呪術). Please shoot me a Koku-Senn(黒閃).
- glandium 3y ago柔術 is actually Jūjutsu (or Juujutsu), while 呪術 is Jujutsu, ironically.
- caymanjim 3y agoI can't stand Git. The points the author makes in the intro are true. Developers learn just enough Git to do their jobs, which is unfortunately more Git than they actually understand. I'm including myself in this. I've been using Git for nearly 20 years (since the very beginning), and I still can't accomplish anything more than the most basic things without reading documentation and hitting up the net for help. Even if I stick with simple operations, I can get in over my head. WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means. I don't know what the reflog is, other than that it has to do with some dark internals. Resolving merge conflicts during a rebase is a clusterfuck. And on any team I've ever worked on, the branch history is a nightmare to look at. So I clicked on this link with the hope that it might be a kinder, simpler VCS. Especially after the article author talked about how bad Git's CLI is and how much better Jujutsu's is. But it looks like it's just as much of an overcomplicated clusterfuck, and since it's built on top of Git, you still get to experience all the pain of Git if anything goes wrong. And I wonder what kind of frightening scenario occurs when some contributors use Jujutsu and some use Git. I understand that Git is powerful, and many of its features are valuable for large teams working on enormous projects (like the Linux kernel it was invented to manage). Hardly anyone needs that, though. I want a dead simple VCS for small project use that doesn't come with so many footguns. I know simpler VCS exists, but without wide adoption, GitHub-like repos, and tooling support, using Git is still the path of least resistance.
- wsatb 3y agoBut how often do you really need more than the basics? I think you're probably doing something wrong if you constantly need to look up docs on it. If you're not constantly doing that, it sounds pretty good. Takes care of the basics and the more complicated features stay out of the way.
- never_inline 3y ago> So I clicked on this link with the hope that it might be a kinder, simpler VCS. Last thing we want is a kinder, simpler, dumber VCS replacing git, like microframeworks which hardly have HTTP routing and middleware replaced full featured frameworks.
- k8svet 3y agoI love 'jj'. I would easily bet on it if I could. I know it's HN and the criticism is almost a badge of honor, but I really hope people try it out. I also use `jj` without anyone else knowing. I get to smile a relieved smile when coworkers talk about making mistakes with git rebase/reset -f/stash. I don't sweat stacked patch sets. I never, ever, ever lose work. Ever. Never. Not even in my worst fat-finger, because of the oplog. It's really good. Please form your own opinion from trying it. I also find the article a bit too lengthy to easily digest.
- actinium226 3y agoYou had me until the part with the log. You didn't show the log, you simply explained how the jj log is confusing and not intuitive at first, and then there was a dive into some functional topics and an explanation of syntax (all while we haven't seen the log) and some more shitting on git. By the time I got to the changes section I was a bit too tired to keep reading.
- chriskrycho 3y agoThis is a fair criticism. I struggled with how to organize that section and I might go back and add an example of what I meant, or even pull that phrase out (it’s actually from a much earlier version of the piece when it was more experience report and less introduction to the tool). I also debated about showing various bits of log output for exactly this reason, but decided not to since there are multiple examples of it in the asciinema recordings. Also, “a bit too tired to keep reading” is indicative of the other reason: this is already a mammoth piece of writing to work through! There is room to deep dive on any of the pieces as their own standalone pieces, too, but at some point I just had to publish the dang thing.
- wsve 3y agoSomething that would have been really helpful to me: If the big pitch is "how easy it is" and "the mental model", get to that part sooner! Put up some pictures of what I'm supposed to visualize when I'm dealing with merge conflicts, and the simple commands mapping easily to that mental model. I also read a ton of paragraphs excited about an easier Git, but I just couldn't understand what you were talking about and how it make my life easier. What does it mean to make merge conflicts first class?
- m3kw9 3y agoGit bisect, reflog useful but really a pain to use on the command line. There should be a GUI first class citizen for next gen source repos. You build the gui for every command you add.
- lanza 3y agoI love the ideas of jj but `jj split` is just an awful workflow. Splitting commits is too important of a feature to get right and jj gets it really wrong.
- chriskrycho 3y agoI initially thought the same but have come around. The problem at this point is the lack of tooling that understands and supports it. You could, quite reasonably, say they should have made a different choice based on what works best with tooling today, and that would be fair; but I think that would leave us in a bit of a local maximum. My hope is that if and as it catches on, tools will grow feature and modes to work with it—just like they did to work with Git’s index.
- amluto 3y agoI haven’t tried jj yet, but from my reading of the article, 80% of the problem is that jj split is backwards for some (most?) uses. You seem to want to split a change such that the newly split piece goes before the part you leave alone, and jj split wants to do the opposite. Certainly when I split a change up in git or hg, I’m usually trying to break off a piece that goes before the rest. TortoiseHG’s committer works like that — you select the parts to commit, and the rest stays uncommitted in the working copy. So maybe the only tooling needed to make jj better is a mode (or maybe a default) that reverses the initial guess as to which parts of the change go where.
- chriskrycho 3y agoMight have been a lack of clarity on my part. When you split, you are actually choosing "what goes first". The issue workflow-wise today is primarily a lack of tooling designed to represent this process visually in an easy way.
- wrs 3y agoIf I understood correctly, the problem is that the default is that everything “goes first” and you have to remove the hunks you want to go second. As if in a Git tool everything defaulted to “staged” and you had to click “unstage” on what you want to go second, which is the reverse of what they all do. Except…when you’re actually splitting an existing commit with interactive rebase, don’t Git tools make you unstage changes that should go second? I see how it’s backwards and annoying compared to “git add -p” for a new commit, but they seem equally bad for splitting existing ones.
- reactordev 3y agoThe issue with people learning git is they learn all this construction around it without actually learning what it is. Branches aren’t real, it’s just a series of commits in time. Like a blockchain, the sha’s must match the previous (that forms the line/branch/tree/root/wtf ever). A HEAD is the end of that line. A detached head is when you have checked out a sha that isn’t the end. Once you throw out the concepts of branches and things, that they are just labels, like tags, moments in time with a previous moment in time. HEAD~1 goes back one node from the head, HEAD~5 will go back 5. You see? It’s easy, it’s simple, it’s not hard. You can revert, you can —amend, you can even stash your changes
- mianos 3y agoIn the article, it's pointing out that the go-to advice when someone's struggling with tech is often "you need to understand how it works." But honestly, having to know the ins and outs just to use something isn't really practical. I mean, I personally geek out over the details, but let's be real: most folks, especially those not in software development, don't work like that. Even for us developers, you don't need to know the nitty-gritty of machine code to whip up some Python scripts. Sure, some of us love diving into that stuff, but it definitely shouldn't be a must.
- reactordev 3y ago"But honestly, having to know the ins and outs just to use something isn't really practical." This is why we have buffer overflows...
- letslearn 3y agoExcept these are _developers_, people who are, ostensibly, computer experts. Yes, computers are hard! And version control is a hard problem. I don't expect grandma to learn git, but nobody suggested otherwise. If we can't expect software developers to learn their basic tools, then I really don't know where we go from here. Let's stop making excuses for mediocrity.
- orev 3y ago
- xedrac 3y agoThis looks interesting, and I will try it out, but I don't feel any friction using git directly. The only exception is rebasing in some situations can be very annoying, and git LFS. How does JJ deal with submodules, subtrees, and LFS objects?
- memco 3y agoLots to digest here! I have been keeping an eye on Pijul so it is cool to see some of its features implemented in jj. Sapling[0], similarly, is a new VCS tool out there which can work with a git repo. It also has anonymous branches, no staging area, supports stacked commits and can track the history of a commit over time. I've been using a similar workflow to the article's author: git with a UI to handle commits of hunks of a file to group related changes. My working branch often has unrelated changes that get tossed from branch to branch as I am able to commit. I haven't figured out where these new tools fit into my workflow yet, but I am glad there's new options that will help making working on a project more flexible and organized. [0]: https://sapling-scm.com https://sapling-scm.com
- rich_sasha 3y agoTo be honest, git is really close to perfect, except for the interface, which is horrendous. I don't think, personally, there's a pressing need for something substantially different. I'd imagine a binary that replaces git commands with other, saner ones, will do 95% of the work, while retaining compatibility with both past repos and the whole world wanting to use git.
- snovymgodym 3y agoI really liked using Sapling internally at Meta (they call it hg/mercurial internally, lots of people don't even know it's not actually hg under the hood). Is the publicly available version of Sapling usable? I really miss stacked diffs every time I'm working on a GitHub project. Last I checked it seemed there were some dependencies on Mononoke and EdenFS which are not open source.
- jolux 3y ago> Is the publicly available version of Sapling usable? Yes — I've been using it as a Git replacement for a few months now. A little rough around the edges but mostly it just feels like a better Git to me.
- pmeunier 3y agoNone of pijul's feature have been implemented in Jujutsu. No change commutativity, no associativity, no actual modelling of conflicts. Jujutsu is a better `git rerere`: a good heuristic, but not an algorithm. Of course if there is an algorithm at some point, it would be really cool to see it described somewhere.
- amluto 3y agoIn “REVISIONS AND REVSETS”, you say “Revisions are the fundamental elements of changes in Jujutsu, not “commits” as in Git. But then you proceed to use “revision” and “commit” apparently interchangeably, and you don’t explain whether there is a difference. You also lost me a bit on “change”. What is a change? If I modify a change, does it keep the same id? What if I send you a change and then modify it? At what point are changes immutable? What if I end up with two changes with the same id that aren’t the same change in my repo? The asciinema casts might have helped a bit, but the lack of scrolling or an easy scrubber makes it really hard to follow.
- chriskrycho 3y agoAh, you’re right. I will try to clarify that in edits tomorrow or Monday. Thanks for flagging it up!
- krupan 3y ago"Maybe the little bit of extra friction when you do want to push a branch is worth it for all the times you do not have to consciously move a branch backwards to avoid pushing changes you are not yet ready to share." Very True. This whole article really makes me miss mercurial. No need to create branches all the time, very rarely needing rebase -i, revsets, simple commands, those were the days! I'm almost afraid to give jj a try because I'll fall in love and probably lose it again and have to go back to git
- multani 3y agoInteresting discussion about `jj split` and how it opens up a GUI tool to select what changes you want to pick. I'm using `git gui` a lot, I think about everydays, to pick up exact what I want to commit or amend my current work. It's not a very fancy tool, but it ships with git by default and I feel it's really underused and could actually make people's life easier for editing undergoing work...