[HN Gopher] The Jujutsu version control system
___________________________________________________________________
The Jujutsu version control system
Author : imajoredinecon
Score : 94 points
Date : 2024-12-22 18:29 UTC (4 hours ago)
(HTM) web link (neugierig.org)
(TXT) w3m dump (neugierig.org)
| forrestthewoods wrote:
| I'm quite happy with Sapling at work. I still haven't figured out
| what Jujutsu does better. I think nothing substantial? Not that
| Sapling can be easily used in the public sphere. But at a
| conceptual level I'm not sure there's anything in JJ I'm missing.
| bsder wrote:
| Sapling is Mercurial with some advancements. Mercurial is
| ridiculously better than git, but lost the network effects
| battle due to Github. So, JJ probably doesn't give you anything
| amazing.
|
| JJ is useful for those of us who understand the shittiness of
| Git but have to work in a world that got locked into path
| dependent network effects by VC money.
| CharlieDigital wrote:
| From the blog: > When I left Google three
| years ago I recall they were trying to figure out what to do
| about either making Git scale, or adopting Mercurial, or
| what.
|
| It's interesting because I used Mercurial (hg) for close to a
| decade after coming from Subversion.
|
| Rarely had to consult the docs for weird edge cases and
| generally operation felt natural and seamless. It was easy to
| onboard new devs of all experience levels.
|
| I switched to git 5 years back and I still feel lost
| sometimes and inadvertently end up in detached head state
| once in a while. Git feels really "unnatural" or
| "unintuitive" to me in some way that Mercurial never did (I
| can't put my finger on why because I never gave Mercurial
| much thought).
| sunshowers wrote:
| You're like most developers! The core problem is that Git's
| workflow treats branches as the source of truth for what's
| in the repo, while Mercurial and its progeny (Jujutsu and
| Sapling) treat individual commits as the source of truth.
| The latter is vastly simpler, and also (as Jujutsu shows)
| more powerful.
|
| While working on a stack of changes, you should be able to
| check out an earlier commit, amend it, and have its
| descendants be automatically rebased. _Of course_ you
| should be able to -- this is a natural and straightforward
| way to think about working on changes, and builds on prior
| knowledge about how to work with individual commits and how
| to rebase them onto a newer upstream. Now compare this to
| git rebase -i.
| samatman wrote:
| Git succeeded to large degree because of GitHub, yes. But
| that isn't how it happened at all. They built an amazing
| product that people loved, there was nothing even vaguely
| like it before, and it earned its adoption through providing
| a superior product than the competition, by leaps and bounds.
|
| It ended on a bitter note when Microsoft bought them, sure.
| But let's not rewrite history, GitHub was not dumped on the
| market by deep-pocketed VCs. GitHub was self-funded from 2007
| to 2012, at which point it was wildly popular and used a big
| cash injection to get to where it is now. By the time that
| happened it had the #1 position in commits per month and was
| about to become #1 in repos hosted also.
| layer8 wrote:
| Git and Mercurial both were initially released in the same
| month (April 2005), and DVCSs had existed for some time
| before [0]. Linus even considered Monotone, which is also
| based on SHA-1 hashes, as a replacement for Bitkeeper
| before starting his own Git. Most people who worked with
| both Mercurial and Git consider Mercurial's UI to be
| superior. It was mostly the draw of Linus and then GitHub
| that made Git "win".
|
| [0] https://en.wikipedia.org/wiki/Distributed_version_contr
| ol#Hi...
| riwsky wrote:
| You aren't contradicting your parent; neither Linus nor
| GitHub were VC money dumps.
| fragmede wrote:
| Mercurial was slow, right when it mattered, and didn't have
| the Linux kernel using it. GitHub's VC funding helped, for
| sure, but that had more to do with the rise of GitHub over
| Gitlab, SourceForge, Google Code, and BitBucket than the
| success of git itself. Getting people to switch RCSes has a
| bootstrapping problem that the Linux kernel solved for git.
| Firefox was on Mercurial/hg, as was CPython, but neither of
| those have the same ecosystem of developers.
|
| if you take the time to learn it, the underlying data model
| for git makes sense, leading to the tools making sense, for
| those that put in the time investment to understand the
| underlying data model. This meant that there was a bunch of
| git expertise floating around IRC and mailing lists. Git
| tooling also wasn't super opinionated, letting pre-git
| workflows be run on git with little modification (which is
| also its problem, but does drive adoption). Sure, a
| recommended workflow has emerged, but that came later. By the
| time GitHub started in 2008, that was three years after its
| invention and use on the Linux kernel and git already had the
| mindshare and intertia. Without VC funding, GitLab or
| BitBucket or even Google Code might be the dominant platform,
| but it really was git's speed and fast branching, and proven
| scalability from managing Linux kernel development that led
| to git's rise as the preferred solution. (Its inability to
| handle monorepos like Google/Meta wasn't an issue for that
| time.)
|
| Mercurial's lack of speed and inflexibility are what hurt
| adoption. VC money pouring in might have saved it, by somehow
| addressing those two issues, but unfortunately we'll never
| know. Mercurial's workflow is pretty central though so I
| doubt its community would have supported changes to the
| central workflow. Moving from Subversion to a DVCS (aka
| mercurial/hg or git) required learning a new tool and being
| forced to change workflow on top of that made the decision to
| go with git easier since a git expert could make a company-
| specific cheat sheet that didn't also require learning and
| adapting to a new way of working at the same time.
|
| Most of the world was on SVN by the time git came around, and
| Git-svn was a pretty popular adapter. You could use git and
| its fast local branching before the company turned to git. I
| really can't stress the fast local branching enough as a
| reason for git winning. SVN server-side branches took forever
| to be created (even with the underlying data not actually
| being copied) and I remember even just running "hg" and no
| arguments being slow.
|
| VC funding helped GitHub, but git still would have won out
| because hg didn't have a dev community to rival the Linux
| Kernel. Maybe Wikipedia/Wikimedia, but that's a much smaller
| codebase.
| sunshowers wrote:
| > I remember even just running "hg" and no arguments being
| slow.
|
| This was definitely a really big complaint. Python's just
| slow to start up, and last I checked Python 3 makes things
| even worse here.
|
| Startup time really made me believe that the optimal
| language to write CLI tools is Rust.
| pimeys wrote:
| That and the great libraries Rust have for CLI apps.
| Really good stuff, and you can get productive quickly.
| sunshowers wrote:
| Sapling is great. I worked on it for many years at Facebook and
| I think we did a pretty good job building a workflow that most
| developers preferred to Git.
|
| To the extent that Jujutsu is similar to any other systems, it
| is most similar to Sapling -- both have a Mercurial heritage
| (Sapling is derived from hg, while Jujutsu is a new codebase
| with an hg-inspired UX). However, Jujutsu introduces a number
| of fantastic improvements over Sapling, such as first-class
| merge conflicts and automatic working copy snapshots. See my
| testimonial, the top one on this page:
|
| https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...
|
| I no longer do VCS development, but I'm a very happy full-time
| jj user. I've also helped onboard a number of people onto it.
|
| (Personally, I'm just happy that after the dark era of Git's
| branch-first UX being dominant, the anonymous heads/commit-
| first UX pioneered by Mercurial is making a resurgence. The
| vast majority of developers prefer a commit-first UX, and it is
| so much easier to explain things like stacked commits if you
| don't have to introduce git rebase -i.)
| gcr wrote:
| I use jj for all my projects on github! It's really useful for my
| sort of workflow: chains of commits with easily-editable history.
| If you make a change back in time, you edit the previous commit
| (which puts you in a state similar to git's detached head), and
| any edits you make there are automatically carried forward
| (rebased) onto descendants. It feels way more natural, especially
| for newer users.
|
| The killer feature that I love the most is a small one, but it's
| that commit messages can be made ahead of time rather than after-
| the-fact. So I can sit down at my desk, say jj
| new -m "Work on XYZ feature"
|
| then edit my code in the editor. When I'm finished, I move on to
| the next commit: jj new -m "Working on UVW
| feature"
|
| No more "oh no I accidentally started touching code and forgot to
| commit my work, so now I have to manually split two git commits;"
| it's a small way that the tooling encourages you to be
| intentional about your engineering philosophy.
| frizlab wrote:
| This might be the single most compelling reason I've ever read
| to try jj. I won't, but thanks for this particular feedback.
| ghfhghg wrote:
| Sounds kind of like perforce
| fragmede wrote:
| I use git add -p to deal with that particular issue, but it's
| great that other people are making and finding tools that work
| for them.
| ibejoeb wrote:
| Same. I love the power and flexibility. But, then again, I
| sometimes found myself spending a nontrivial amount of time
| planning my git maneuvers. That was a bit taxing. Either it
| took away from the focus on the objective, or it was enough
| of a chore that it I felt a little worn, especially during
| intense working sessions. I don't get that as much with jj.
| miki123211 wrote:
| > It feels way more natural, especially for newer users.
|
| I have thought about this recently, and it feels like jj would
| be a lot easier to teach to new users than git.
|
| For one, jj lets you work on things directly without having to
| worry about an index, while still giving you all the advantages
| of one if you're advanced enough to need that.
|
| THe commands also feel a lot easier to explain than in git. For
| example, you use `edit` to change what commit you're working
| on, `restore` to copy a file from a commit to your working
| directory (and abandon your changes to it), and `abandon` to
| drop a commit completely. Meanwhile, git has `checkout`,
| `restore`, `switch`, `reset` and `reset --hard`, which all do
| various parts of one or more of these.
| 3eb7988a1663 wrote:
| Reading the jj changelog is fun where you see them deprecate
| functions, acknowledging that they perform identical
| purposes. Beautiful to see this simplification that benefits
| all users going forward.
|
| The one that stood out in my mind: `jj
| checkout` and `jj merge` are both deprecated; use `jj new`
| instead to replace both of these commands in all instances.
| Rationale: jj checkout and jj merge both implement identical
| functionality, which is a subset of jj new. checkout creates
| a new working copy commit on top of a single specified
| revision, i.e. with one parent. merge creates a new working
| copy commit on top of at least two specified revisions, i.e.
| with two or more parents. The only difference
| between these commands and jj new, which also creates a new
| working copy commit, is that new can create a working copy
| commit on top of any arbitrary number of revisions, so it can
| handle both the previous cases at once. The only actual
| difference between these three commands is the command syntax
| and their name. These names were chosen to be familiar to
| users of other version control systems, but we instead
| encourage all users to adopt jj new instead; it is more
| general and easier to remember than both of these.
| adastra22 wrote:
| You can edit your commit message ahead of time in git too.
| akdor1154 wrote:
| Great article. How do people deal with the lack of branches, esp
| in a full time setting where it's common to have a few
| independent features on the go?
| fprotthetarball wrote:
| There are still branches, but they aren't named by default. You
| give them names with "bookmarks", which you can push to remote
| git repositories as branches.
|
| This lets you work on things without having to worry about
| giving it a name. This turns out to be pretty helpful when
| you're experimenting -- just "jj new <revision>" and start
| editing. If it turns out to be something you want to share, "jj
| bookmark create <name>" and then you can push it. (You can also
| push without giving it a name, in which case you'll get a git
| branch with a name based off of the change id.)
|
| Change IDs stay constant with each change, so you use those as
| a type of branch name when switching between the features
| you're working on.
| J_tt wrote:
| Adding onto this, there's also an experimental feature to
| move a bookmark as you create new revisions (similar to how a
| git branch behaves)
| sunshowers wrote:
| So, with VCS in general you don't really need to have branches
| to be able to track multiple independent changes. (With Git you
| do, but that's an artifact of Git's model, not an inherent
| property of source control.)
|
| What you do need is a good way to visualize what work you have
| in flight. With Jujutsu that's as simple as typing in `jj` on
| the command line.
|
| At Facebook it was common for even junior devs to have 5-6
| changes in flight with nary a branch in sight, and experienced
| devs like myself routinely had dozens.
| thibran wrote:
| How do the rebased commits work when working with others together
| on a branch?
| mpalmer wrote:
| It's no different from how rebasing works in any shared git
| project; rebased commits are re-created with different SHAs.
| setheron wrote:
| The jj community on discord has been great also. It took a while
| for it to sync in but when I use git now it feels "wrong"
| dang wrote:
| Recent and related:
|
| _I 'm daily driving Jujutsu, and maybe you should too_ -
| https://news.ycombinator.com/item?id=42380306 - Dec 2024 (47
| comments)
|
| Others:
|
| _Git and Jujutsu: In Miniature_ -
| https://news.ycombinator.com/item?id=42111597 - Nov 2024 (72
| comments)
|
| _Jujutsu (jj), a Git compatible VCS_ -
| https://news.ycombinator.com/item?id=41895056 - Oct 2024 (110
| comments)
|
| _Steve 's Jujutsu Tutorial_ -
| https://news.ycombinator.com/item?id=41881204 - Oct 2024 (116
| comments)
|
| _Jujutsu Strategies_ -
| https://news.ycombinator.com/item?id=41468750 - Sept 2024 (1
| comment)
|
| _Jujutsu: A Next Generation Replacement for Git_ -
| https://news.ycombinator.com/item?id=40908985 - July 2024 (80
| comments)
|
| _Lazyjj: TUI for Jujutsu /Jj_ -
| https://news.ycombinator.com/item?id=40859315 - July 2024 (1
| comment)
|
| _A better merge workflow with Jujutsu_ -
| https://news.ycombinator.com/item?id=40842762 - July 2024 (90
| comments)
|
| _GG, a GUI for Jujutsu_ -
| https://news.ycombinator.com/item?id=39713896 - March 2024 (2
| comments)
|
| _jj init - getting serious about replacing Git with Jujutsu_ -
| https://news.ycombinator.com/item?id=39232456 - Feb 2024 (110
| comments)
|
| _Jujutsu: A Git-compatible DVCS that is both simple and
| powerful_ - https://news.ycombinator.com/item?id=36952796 - Aug
| 2023 (261 comments)
|
| _Jujutsu: A Git-compatible DVCS that is both simple and
| powerful_ - https://news.ycombinator.com/item?id=36371138 - June
| 2023 (1 comment)
|
| _Jujutsu - A Git-compatible DVCS that is both simple and
| powerful_ - https://news.ycombinator.com/item?id=30398662 - Feb
| 2022 (228 comments)
| sam_goody wrote:
| What front ends work with jujutsu? Do I have to start doing all
| on the command line?
___________________________________________________________________
(page generated 2024-12-22 23:00 UTC)