[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5362":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":25,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":27,"readmeContent":28,"aiSummary":29,"trendingCount":16,"starSnapshotCount":16,"syncStatus":30,"lastSyncTime":31,"discoverSource":32},5362,"jj","jj-vcs\u002Fjj","jj-vcs","A Git-compatible VCS that is both simple and powerful","https:\u002F\u002Fjj-vcs.dev",null,"Rust",29559,1085,101,783,0,17,145,804,92,44.11,"Apache License 2.0",false,"main",true,[],"2026-06-12 02:01:09","\u003Cdiv class=\"title-block\" style=\"text-align: center;\" align=\"center\">\n\n# Jujutsu—a version control system\n\n\u003Cp>\u003Cimg title=\"jj logo\" src=\"docs\u002Fimages\u002Fjj-logo.svg\" width=\"320\" height=\"320\">\u003C\u002Fp>\n\n[![Release](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002Fmartinvonz\u002Fjj)](https:\u002F\u002Fgithub.com\u002Fjj-vcs\u002Fjj\u002Freleases)\n[![Release date](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Frelease-date\u002Fmartinvonz\u002Fjj)](https:\u002F\u002Fgithub.com\u002Fjj-vcs\u002Fjj\u002Freleases)\n\u003Cbr\u002F>\n[![License](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Flicense\u002Fmartinvonz\u002Fjj)](https:\u002F\u002Fgithub.com\u002Fjj-vcs\u002Fjj\u002Fblob\u002Fmain\u002FLICENSE)\n[![Discord](https:\u002F\u002Fimg.shields.io\u002Fdiscord\u002F968932220549103686.svg?label=&logo=discord&logoColor=ffffff&color=7389D8&labelColor=6A7EC2)](https:\u002F\u002Fdiscord.gg\u002Fdkmfj3aGQN)\n[![IRC](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Firc-%23jujutsu-blue.svg)](https:\u002F\u002Fweb.libera.chat\u002F?channel=#jujutsu)\n\n**[Homepage]   •  **\n**[Installation]   •  **\n**[Getting Started]   •  **\n**[Development Roadmap]   •  **\n**[Contributing](#contributing)**\n\n[Homepage]: https:\u002F\u002Fwww.jj-vcs.dev\n[Installation]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Finstall-and-setup\n[Getting Started]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Ftutorial\n[Development Roadmap]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Froadmap\n\n\u003C\u002Fdiv>\n\n## Introduction\n\nJujutsu is a powerful [version control system](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FVersion_control)\nfor software projects. You use it to get a copy of your code, track changes\nto the code, and finally publish those changes for others to see and use.\nIt is designed from the ground up to be easy to use—whether you're new or\nexperienced, working on brand new projects alone, or large scale software\nprojects with large histories and teams.\n\nJujutsu is unlike most other systems, because internally it abstracts the user\ninterface and version control algorithms from the *storage systems* used to\nserve your content. This allows it to serve as a VCS with many possible physical\nbackends, that may have their own data or networking models—like [Mercurial] or\n[Breezy], or hybrid systems like Google's cloud-based design, [Piper\u002FCitC].\n\n[Mercurial]: https:\u002F\u002Fwww.mercurial-scm.org\u002F\n[Breezy]: https:\u002F\u002Fwww.breezy-vcs.org\u002F\n[Piper\u002FCitC]: https:\u002F\u002Fyoutu.be\u002FW71BTkUbdqE?t=645\n\nToday, we use Git repositories as a storage layer to serve and track content,\nmaking it **compatible with many of your favorite Git-based tools, right now!**\nHowever, note that only commits and files are stored in Git; bookmarks\n(branches) and other higher-level metadata are stored in custom storage outside\nof Git. All core developers use Jujutsu to develop Jujutsu, right here on\nGitHub. But it should hopefully work with your favorite Git forges, too.\n\nWe combine many distinct design choices and concepts from other version control\nsystems into a single tool. Some of those sources of inspiration include:\n\n- **Git**: We make an effort to [be fast][perf]—with a snappy UX, efficient\n  algorithms, correct data structures, and good-old-fashioned attention to\n  detail. The default storage backend uses Git repositories for \"physical\n  storage\", for wide interoperability and ease of onboarding.\n\n- **Mercurial & Sapling**: There are many Mercurial-inspired features, such as\n  the [revset] language to select commits. There is [no explicit index][no-index]\n  or staging area. Branches are \"anonymous\" like Mercurial, so you don't need\n  to make up a name for each small change. Primitives for rewriting history are\n  powerful and simple. Formatting output is done with a robust template language\n  that can be configured by the user.\n\n- **Darcs**: Jujutsu keeps track of conflicts as [first-class\n  objects][conflicts] in its model; they are first-class in the same way commits\n  are, while alternatives like Git simply think of conflicts as textual diffs.\n  While not as rigorous as systems like Darcs (which is based on a formalized\n  theory of patches, as opposed to snapshots), the effect is that many forms of\n  conflict resolution can be performed and propagated automatically.\n\n[perf]: https:\u002F\u002Fgithub.com\u002Fjj-vcs\u002Fjj\u002Fdiscussions\u002F49\n[revset]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Frevsets\u002F\n[no-index]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fgit-comparison\u002F#the-index\n[conflicts]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fconflicts\u002F\n\nAnd it adds several innovative, useful features of its own:\n\n- **Working-copy-as-a-commit**: Changes to files are [recorded automatically][wcc]\n  as normal commits, and amended on every subsequent change. This \"snapshot\"\n  design simplifies the user-facing data model (commits are the only visible\n  object), simplifies internal algorithms, and completely subsumes features like\n  Git's stashes or the index\u002Fstaging-area.\n\n- **Operation log & undo**: Jujutsu records every operation that is performed on the\n  repository, from commits, to pulls, to pushes. This makes debugging problems like\n  \"what just happened?\" or \"how did I end up here?\" easier, *especially* when\n  you're helping your coworker answer those questions about their repository!\n  And because everything is recorded, you can undo that mistake you just made\n  with ease. Version control has finally entered [the 1960s][undo-history]!\n\n- **Automatic rebase and conflict resolution**: When you modify a commit, every\n  descendent is automatically rebased on top of the freshly-modified one. This\n  makes \"patch-based\" workflows a breeze. If you resolve a conflict in a commit,\n  the _resolution_ of that conflict is also propagated through descendants as\n  well. In effect, this is a completely transparent version of `git rebase\n  --update-refs` combined with `git rerere`, supported by design.\n\n> [!WARNING]\n> The following features are available for use, but experimental; they may have\n> bugs, backwards incompatible storage changes, and user-interface changes!\n\n- **Safe, concurrent replication**: Have you ever wanted to store your version\n  controlled repositories inside a Dropbox folder? Or continuously backup\n  repositories to S3? No? Well, now you can!\n\n  The fundamental problem with using filesystems like Dropbox and backup tools\n  like `rsync` on your typical Git\u002FMercurial repositories is that they rely\n  on *local filesystem operations* being atomic, serialized, and non-concurrent\n  with respect to other reads and writes—which is _not_ true when operating on\n  distributed file systems, or when operations like concurrent file copies (for\n  backup) happen while lock files are being held.\n\n  Jujutsu is instead designed to be [safe under concurrent scenarios][conc-safety];\n  simply using rsync or Dropbox and then using that resulting repository\n  should never result in a repository in a *corrupt state*. The worst that\n  _should_ happen is that it will expose conflicts between the local and remote\n  state, leaving you to resolve them.\n\n[wcc]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fworking-copy\u002F\n[undo-history]: https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FUndo#History\n[conc-safety]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Ftechnical\u002Fconcurrency\u002F\n\nThe command-line tool is called `jj` for now because it's easy to type and easy\nto replace (rare in English). The project is called \"Jujutsu\" because it matches\n\"jj\".\n\nJujutsu is relatively young, with lots of work to still be done. If you have any\nquestions, or want to talk about future plans, please join us on Discord\n[![Discord](https:\u002F\u002Fimg.shields.io\u002Fdiscord\u002F968932220549103686.svg?label=&logo=discord&logoColor=ffffff&color=7389D8&labelColor=6A7EC2)](https:\u002F\u002Fdiscord.gg\u002Fdkmfj3aGQN),\nstart a [GitHub Discussion](https:\u002F\u002Fgithub.com\u002Fjj-vcs\u002Fjj\u002Fdiscussions), or\nsend an IRC message to [`#jujutsu` on Libera\nChat](https:\u002F\u002Fweb.libera.chat\u002F?channel=#jujutsu). The developers monitor all of\nthese channels[^bridge].\n\n[^bridge]: To be more precise, the `#jujutsu` Libera IRC channel is bridged to\none of the channels on jj's Discord. Some of the developers stay on Discord and\nuse the bridge to follow IRC.\n\n### News and Updates 📣\n\n- **December 2024**: The `jj` Repository has moved to the `jj-vcs` GitHub\n  organization.\n- **November 2024**: Version 0.24 is released which adds `jj file annotate`,\n  which is equivalent to `git blame` or `hg annotate`.\n- **September 2024**: Martin gave a [presentation about Jujutsu][merge-vid-2024] at\n  Git Merge 2024.\n- **Feb 2024**: Version 0.14 is released, which deprecates [\"jj checkout\" and \"jj merge\"](CHANGELOG.md#0140---2024-02-07),\n  as well as `jj init --git`, which is now just called `jj git init`.\n- **Oct 2023**: Version 0.10.0 is released! Now includes a bundled merge and\n  diff editor for all platforms, \"immutable revsets\" to avoid accidentally\n  `edit`-ing the wrong revisions, and lots of polish.\n- **Jan 2023**: Martin gave a presentation about Google's plans for Jujutsu at\n  Git Merge 2022!\n  See the [slides][merge-slides] or the [recording][merge-talk].\n\n### Related Media\n\n- **Mar 2024**: Chris Krycho started [a YouTube series about Jujutsu][krycho-yt].\n- **Feb 2024**: Chris Krycho published an article about Jujutsu called [jj init][krycho]\n  and Steve Klabnik followed up with the [Jujutsu Tutorial][klabnik].\n- **Jan 2024**: Jujutsu was featured in an LWN.net article called\n  [Jujutsu: a new, Git-compatible version control system][lwn].\n- **Jan 2023**: Martin's Talk about Jujutsu at Git Merge 2022, [video][merge-talk]\n  and the associated [slides][merge-slides].\n\nThe wiki also contains a more extensive list of [media references][wiki-media].\n\n[krycho-yt]: https:\u002F\u002Fwww.youtube.com\u002Fplaylist?list=PLelyiwKWHHAq01Pvmpf6x7J0y-yQpmtxp\n[krycho]: https:\u002F\u002Fv5.chriskrycho.com\u002Fessays\u002Fjj-init\u002F\n[klabnik]: https:\u002F\u002Fsteveklabnik.github.io\u002Fjujutsu-tutorial\u002F\n[lwn]: https:\u002F\u002Flwn.net\u002FArticles\u002F958468\u002F\n[merge-talk]: https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=bx_LGilOuE4\n[merge-slides]: https:\u002F\u002Fdocs.google.com\u002Fpresentation\u002Fd\u002F1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M\u002Fview\n[merge-vid-2024]: https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=LV0JzI8IcCY\n[wiki-media]: https:\u002F\u002Fgithub.com\u002Fjj-vcs\u002Fjj\u002Fwiki\u002FMedia\n\n## Getting started\n\n> [!IMPORTANT]\n> Jujutsu is an **experimental version control system**. While Git compatibility\n> is stable, and most developers use it daily for all their needs, there may\n> still be work-in-progress features, suboptimal UX, and workflow gaps that make\n> it unusable for your particular use.\n\nFollow the [installation\ninstructions](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Finstall-and-setup) to\nobtain and configure `jj`.\n\nThe best way to get started is probably to go through [the\ntutorial](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Ftutorial). Also see the [Git\ncomparison](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fgit-comparison), which\nincludes a table of `jj` vs. `git` commands.\n\nAs you become more familiar with Jujutsu, the following resources may be helpful:\n\n- The [FAQ](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002FFAQ).\n- The [Glossary](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fglossary).\n- The `jj help` command (e.g. `jj help rebase`).\n- The `jj help -k \u003Ckeyword>` command (e.g. `jj help -k config`). Use `jj help --help`\n  to see what keywords are available.\n\nIf you are using a **prerelease** version of `jj`, you would want to consult\n[the docs for the prerelease (main branch)\nversion](https:\u002F\u002Fdocs.jj-vcs.dev\u002Fprerelease\u002F). You can also get there\nfrom the docs for the latest release by using the website's version switcher. The version switcher is visible in\nthe header of the website when you scroll to the top of any page.\n\n## Features\n\n### Compatible with Git\n\nJujutsu is designed so that the underlying data and storage model is abstract.\nToday, only the Git backend is production-ready. The Git backend uses the\n[gitoxide](https:\u002F\u002Fgithub.com\u002FByron\u002Fgitoxide) Rust library.\n\n[backends]: https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fglossary#backend\n\nThe Git backend is fully featured and maintained, and allows you to use Jujutsu\nwith any Git remote. The commits you create will look like regular Git commits.\nYou can fetch branches from a regular Git remote and push branches to the\nremote. You can always switch back to Git.\n\nHere is how you can explore a GitHub repository with `jj`.\n\n\u003Cimg src=\"demos\u002Fgit_compat.png\" \u002F>\n\nYou can even have a [colocated local\nworkspace](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fgit-compatibility#colocated-jujutsugit-repos)\nwhere you can use both `jj` and `git` commands interchangeably.\n\n### The working copy is automatically committed\n\nJujutsu uses a real commit to represent the working copy. Checking out a commit\nresults in a new working-copy commit on top of the target commit. Almost all\ncommands automatically amend the working-copy commit.\n\nThe working-copy being a commit means that commands never fail because the\nworking copy is dirty (no \"error: Your local changes to the following\nfiles...\"), and there is no need for `git stash`. Also, because the working copy\nis a commit, commands work the same way on the working-copy commit as on any\nother commit, so you can set the commit message before you're done with the\nchanges.\n\n\u003Cimg src=\"demos\u002Fworking_copy.png\" \u002F>\n\n### The repo is the source of truth\n\nWith Jujutsu, the working copy plays a smaller role than with Git. Commands\nsnapshot the working copy before they start, then they update the repo, and then\nthe working copy is updated (if the working-copy commit was modified). Almost\nall commands (even checkout!) operate on the commits in the repo, leaving the\ncommon functionality of snapshotting and updating of the working copy to\ncentralized code. For example, `jj restore` (similar to `git restore`) can\nrestore from any commit and into any commit, and `jj describe` can set the\ncommit message of any commit (defaults to the working-copy commit).\n\n### Entire repo is under version control\n\nAll operations you perform in the repo are recorded, along with a snapshot of\nthe repo state after the operation. This means that you can easily restore to\nan earlier repo state, simply undo your operations one-by-one or even _revert_ a\nparticular operation which does not have to be the most recent one.\n\n\u003Cimg src=\"demos\u002Foperation_log.png\" \u002F>\n\n### Conflicts can be recorded in commits\n\nIf an operation results in\n[conflicts](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Fglossary#conflict),\ninformation about those conflicts will be recorded in the commit(s). The\noperation will succeed. You can then resolve the conflicts later. One\nconsequence of this design is that there's no need to continue interrupted\noperations. Instead, you get a single workflow for resolving conflicts,\nregardless of which command caused them. This design also lets Jujutsu rebase\nmerge commits correctly (unlike both Git and Mercurial).\n\nBasic conflict resolution:\n\n\u003Cimg src=\"demos\u002Fresolve_conflicts.png\" \u002F>\n\nJuggling conflicts:\n\n\u003Cimg src=\"demos\u002Fjuggle_conflicts.png\" \u002F>\n\n### Automatic rebase\n\nWhenever you modify a commit, any descendants of the old commit will be rebased\nonto the new commit. Thanks to the conflict design described above, that can be\ndone even if there are conflicts. Bookmarks pointing to rebased commits will be\nupdated. So will the working copy if it points to a rebased commit.\n\n### Comprehensive support for rewriting history\n\nBesides the usual rebase command, there's `jj describe` for editing the\ndescription (commit message) of an arbitrary commit. There's also `jj diffedit`,\nwhich lets you edit the changes in a commit without checking it out. To split\na commit into two, use `jj split`. You can even move part of the changes in a\ncommit to any other commit using `jj squash -i --from X --into Y`.\n\n## Status\n\nThe tool is fairly feature-complete, but some important features like support\nfor Git submodules are not yet completed. There\nare also several performance bugs. It's likely that workflows and setups\ndifferent from what the core developers use are not well supported, e.g. there\nis no native support for email-based workflows.\n\nToday, all core developers use `jj` to work on `jj`. I (Martin von Zweigbergk)\nhave almost exclusively used `jj` to develop the project itself since early\nJanuary 2021. I haven't had to re-clone from source (I don't think I've even had\nto restore from backup).\n\nThere *will* be changes to workflows and backward-incompatible changes to the\non-disk formats before version 1.0.0. For any format changes, we'll try to\nimplement transparent upgrades (as we've done with recent changes), or provide\nupgrade commands or scripts if requested.\n\n## Related work\n\nThere are several tools trying to solve similar problems as Jujutsu. See\n[related work](https:\u002F\u002Fdocs.jj-vcs.dev\u002Flatest\u002Frelated-work) for details.\n\n## Contributing\n\nWe welcome outside contributions, and there's plenty of things to do, so\ndon't be shy. Please ask if you want a pointer on something you can help with,\nand hopefully we can all figure something out.\n\nWe do have [a few policies and\nsuggestions](https:\u002F\u002Fdocs.jj-vcs.dev\u002Fprerelease\u002Fcontributing\u002F)\nfor contributors. The broad TL;DR:\n\n- Bug reports are very welcome!\n- Every commit that lands in the `main` branch is code reviewed.\n- Please behave yourself, and obey the Community Guidelines.\n- There **is** a mandatory CLA you must agree to. Importantly, it **does not**\n  transfer copyright ownership to Google or anyone else; it simply gives us the\n  right to safely redistribute and use your changes.\n\n### Mandatory Google Disclaimer\n\nI (Martin von Zweigbergk, \u003Cmartinvonz@google.com>) started Jujutsu as a hobby\nproject in late 2019, and it has evolved into my full-time project at Google,\nwith several other Googlers (now) assisting development in various capacities.\nThat said, while Google is one of the main contributors, **this is not a\nsupported Google product**, i.e. support is provided by the community.\n\n## License\n\nJujutsu is available as Open Source Software, under the Apache 2.0 license. See\n[`LICENSE`](.\u002FLICENSE) for details about copyright and redistribution.\n\nThe `jj` logo was contributed by J. Jennings and is licensed under a Creative\nCommons License, see [`docs\u002Fimages\u002FLICENSE`](docs\u002Fimages\u002FLICENSE).\n","Jujutsu 是一个与 Git 兼容且既简单又强大的版本控制系统。它使用 Rust 语言开发，具备快速响应的用户界面和高效的算法设计，支持多种物理后端存储系统，如 Mercurial、Breezy 或者 Google 的 Piper\u002FCitC 等。Jujutsu 通过将用户界面和版本控制逻辑从底层存储抽象出来，实现了高度的灵活性和可扩展性。目前，Jujutsu 使用 Git 仓库作为存储层来保存和跟踪内容，这使得它可以与许多现有的基于 Git 的工具无缝集成。该系统适合用于个人独立开发的新项目以及具有复杂历史记录和团队协作需求的大规模软件项目中。",2,"2026-06-11 03:02:51","top_language"]