18 ms·

Jujutsu – A Git-compatible DVCS that is both simple and powerful

568 points by rolisz 5y ago

AnonC 5y ago
I’m curious to know if this has any similarities with fossil (https://fossil-scm.org/ https://fossil-scm.org/ ). If it does, it would be nice to see that in the documentation.
- throwaway81523 5y ago
  Fossil is ideologically different, it wants to preserve every artifact, no rebasing allowed.
  - cryptonector 5y ago
    That Fossil doesn't support rebase is a fiction, since it supports cherry-pick. All that's missing is a script around cherry-pick, which is all rebase is.
kazinator 5y ago
In git you can reorder any sequence of commits without any conflicts. Howwever, there is no nice "porcelain" for it. The basis for it is the read-tree command. In git, every commit is a snapshot and not a delta. (Repeat that three times.) Any arbitrary snapshots of files can be arranged into a git history. They don't even have to be related. We could take a tarball of GCC, and make that the first commit. Then a tarball of Clang and make that the second commit. The read-tree command will read any commit's state into the index, and from there you can make a commit out of it. To reorder some N commits you're looking at, save all of their hashes somewhere, and then rewind the branch: git reset --hard HEAD~N. Then use git read-tree to read those hashes in whatever order you want, committing them one by one. To reuse their commit messages you have to use commit -C <hash>, though most them likely don't make any sense, because the text of commit messages usually talks about changes between a commit and its main parent. What will happen is that your history now as N commits which represent the same states as the N you had there before, in a different order. For instance if you reverse them, then the oldest commit has all the features (is the same code baseline) as what the newest HEAD was previously. And then the subsequent child commits basically remove all the changes that were made, so the latest now looks like what the N-th looked like. How I sometimes use this: Suppose I made a fairly complex change that I would like to break up so that it is presented as a sequence of two or more states of the code. There are cases when the following workflow is easy: first I make a commit out of the changes. One commit with everything. That commit is what I want the final state to look like. Then I revert some of the changes to produce the state before that state. If I have mostly been adding things, this might consist of just deleting them. Or I can do a git reset --patch HEAD^ to selectively revert. I commit this penultimate state. Then repeat the process: revert some more changes from that one, commit and so on, as many times as I see fit. So what I end up with is the states of the code I want to present as a history, but exactly in the wrong order. Using "git rebase -i" doesn't work nicely; there are ugly conflicts, and some of them have to be encountered twice. Here is where the git read-tree trick comes into play: I simply reverse those exact states of the code to put them in the right order on the branch. After that I might do a rebase -i just to reword the commit messages to frame the code states from the POV of being changes from their parents. You might think: why not just "git commit --patch" from the original working state to produce commits in order. The reason is that doesn't always make sense. For that you had to remember to make the commit as you were working. Because say you refactored something and then made a change. You can't easily do a "git commit --patch" which separates the refactoring from the change. Sure, if you do the refactoring and then a commit, and then make the change, you are good. But suppose you've conflated them already; now what? You can commit everything and then back out the changes that were done on top of the refactoring, and commit that. Then reorder the two states.
- mastazi 5y ago
  > In git, every commit is a snapshot and not a delta. I know this, but also I cannot reconcile this whit what happens when you cherry-pick a commit from another branch. I'm confused because cherry-pick really seems to be taking out the delta not the snapshot. I'm thinking that cherry-pick takes that commit and makes a diff with its parent and then that's what you get when you call it. Is it how it works behind the scenes? I'm also thinking that the fact that each commit has at least one parent means that, conceptually, we can use it as if it was a delta (at least in the case of commit with one parent only), if you get what I mean. EDIT: I'm not familiar with the internals of Git, just a user. Commenting out of curiosity.
  - kazinator 5y ago
    When you cherry-pick a commit from another branch, it's not doing anything like a read-tree to make your current work look like that commit's snapshot state. It's doing something like three-way merge between that commit, your baseline and a common ancestor (I'm guessing: the same one that would be identified by git merge-base <hash0> <hash1>.) That's why cherry-pick identifies conflicts. A cherry-pick deos not just do a diff with its parent 0 and then patch it onto your work. In many cases, that wouldn't work because that's not a three-way-merge, but a two-way merge, which has disadvantages. However: there may be situations when the commits are so distant, it might make sense just to turn that one into a patch and work the patch onto your baseline. Even if that needs manual work, it can be simpler. You will only get conflicts (patch hunk rejects in that case) that are relevant to that change. I've had lots of experience working with patch stacks (both before and after Quilt was introduced to make that a bit easier) so I'm comfortable migrating patches from one code base to another without a three-way-diff process within version control.
    - mastazi 5y ago
      Yes, I agree about distant commits and turning it into a patch. Thank you for explaining the three-way merge between baseline, commit and common ancestor, makes sense.
    - 5y ago
mdaniel 5y ago
That's quite impressive, congratulations! The git comparison docs have: > Start working on a new change based on the <main> branch -- jj co main Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? I actually can't tell from so deep in my "git Stockholm syndrome" whether that distinction is really hard on new users or not, but the fact that git expended the energy meant they thought it was meaningful And, do you have plans on supporting signed commits, either via gpg or the newfound SSH key signing? I'm super excited to try out the conflict resolution mechanism, because that's a major painpoint for my long-lived PR branches
- martinvonz 5y ago
  Thanks! > Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? Actually, isn't "restore" for file operations? My impression was that everyone agrees that `git checkout` does too many different things. In particular, it's both for switching branches and for restoring file content. So they added the new `git switch` and `git restore` with limited scope. I strongly suspect that they would have used `git checkout` for the former if that wasn't already taken by the existing command. > And, do you have plans on supporting signed commits, either via gpg or the newfound SSH key signing? No, that's not something I've even started thinking about. I'll have to read up on how it works in Git first. Patches welcome, though :) > I'm super excited to try out the conflict resolution mechanism, because that's a major painpoint for my long-lived PR branches You mean so you can continuously rebase them without having to resolve conflicts right away? Yes, that's one of the benefits of first-class conflicts. Another benefit, which took me a long time to realize how useful it is, is the auto-rebase feature.
  - mdaniel 5y ago
    > No, that's not something I've even started thinking about. I'll have to read up on how it works in Git first. Patches welcome, though :) I opened an issue and provided links to the docs, and a link to the current way that git implements it: https://github.com/martinvonz/jj/issues/58 https://github.com/martinvonz/jj/issues/58 As I was trying to find the correct command in jj for where to add the new argument, I realized that this may not play nice-nice with jj's commit-everything model, so I'm actually prepared for the issue to be closed WONTFIX :-) As for the patches welcome part, I notice that the Google CLA bot is on your repo. While I do have the CLA signed for my Gmail address, it seemed like some major tomfoolery to try and add my current github email address (and the one which backs my GPG key, to bring this full circle!) to the existing CLA process. Do you intend to keep that CLA mechanism in place, or was it just an oversight?
jareds 5y ago
This looks interesting and I'm glad to see that people are not viewing SCM as a solved issue. While I don't think I'd use this on professional projects yet I'm interested at looking at this for personal projects since I can use the Git back-end and continue to use Github to host my code. I feel like Git has become such a DeFacto standard that nothing is going to replace it any time soon. I've been programming for long enough to remember feeling the same way about SVN though so I assume something will eventually supplant Git.
- freedomben 5y ago
  I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provides): if I'm working simultaneously on two different branches (for example one branch is a bug fix that requires 20 minutes to build and deploy before I can test it, so I work on other things while it's running), I often have two different checkouts so I can (mostly) avoid having to git stash. That said though, you are probably right something will eventually supplant git. It would be arrogant to think that my failure to imagine something better means there isn't anything.
  - Hendrikto 5y ago
    What you are describing sounds as if you want worktrees: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
    - freedomben 5y ago
      Whoa, thank you! That does look like the answer!
  - jeltz 5y ago
    I totally agree. Back when I used Subversion it felt to me like there obviously must be a better way to version control and that the tool got in my way all the time. Git on the other hand almost always can solve my problems and while some things could be improved (confusing UX, a bit too complex, plus bad handling of conflicts) it is much closer to the right tool for VCS than Subversion ever was.
mberning 5y ago
Congrats and good luck. Git desperately needs a radically simplified and radically consistent set of porcelain interfaces.
cryptonector 5y ago
> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. > The working copy is automatically committed Right, so, the reason the index is powerful is that I get to do `git add -e`, `git commit`, and repeat until I'm done or ready to throw remaining changes away. I very much want the index / workspace distinction. > Automatic rebase > Comprehensive support for rewriting history This is very welcome. At the very least this confirms something important: the fallacious argument that "rebase rewrites history, so it's eeeevil" is finally dead.
- yjftsjthsd-h 5y ago
  If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?
  - bonzini 5y ago
    The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.
    - masklinn 5y ago
      > You do that with a sequence of "git add -p" and "git commit" commands. You can do that with git commit -p.
      - bonzini 5y ago
        True but there's usually a "git diff --staged" in the middle to check what I am committing.
swagonomixxx 5y ago
> A Git-compatible DVCS that is both simple and powerful We all know the dig here - Git is not simple. Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago. Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly because version control _is_ complex. I also don't agree that Git is hard to use. I feel it is an odd goal to try to make everything - even tools that experts use - simple to use, when they are fundamentally not simple. I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.
- martinvonz 5y ago
  > I feel like Git is sufficiently complex - no more than it needs to be and certainly not less. Perhaps the biggest mistake (IMO) was to expose the index to the user. I happened to just watch https://www.youtube.com/watch?v=31XZYMjg93o https://www.youtube.com/watch?v=31XZYMjg93o (by the person behind Gitless). They explain the issues well there.
  - KerrAvon 5y ago
    I haven’t watched that video, but I agree — the index is one of the biggest hurdles to making git easy to understand and use for newcomers. It’s not hard to explain the fundamental model of how git works — it’s hard to explain the UI, and it’s hard to explain the index. If you remove the index, you’re only working with commits, and that simplifies the UI enormously.
  - hinkley 5y ago
    I'm gonna watch this video. What's been bugging me for a long time, as someone who didn't quite get to see all of the supposed ugliness of Subversion (which by description alone sounds an awful lot like the rerere situation with Git, which I have). It really feels to me like a commit identifier should be the combination of a monotonically increasing number and a hash of the content, rather than an either-or. If I merge or rebase branches in git, I lose the index, just as I would in subversion. But at least in svn I have some notion of how far back commit 12345 is in the tree. ac4def2 could be HEAD or four years ago.
dark-star 5y ago
git is already very simple, at least for the 95% of use-cases that I need. add, commit, checkout, push, pull.... maybe a branch and merge here and there, but that's it. Of course I cannot remember how exactly the "git rebase" command works and have to look it up every time, same as all those switches to the "simpler" commands. I guess it all depends on what you need. Python looks really complicated too, if you start by browsing the function and class reference. But for someone starting to learn programming, it is apparently pretty easy (or so I've heard)
freedomben 5y ago
This looks like an interesting project, and I'm glad that people are still thinking about how to improve on version control. That said, building a version control system seems like a problem similar to a social network: the network affect causes an enormous amount of friction. i.e. most people don't want to use it until other people are using it. A vicious cycle. The fact that it's compatible with git as a backend is really great though, and is probably the key to driving adoption. However I have several immediate thoughts that come to mind that cause me hesitancy. Answers in the README.md would be super helpful for marketing to me (and deep apology if it's there and I missed it): 1. How does it look to others working on the repo using just git? For example, "when the working copy is automatically committed," where does it go? is there a remote branch that someone could see if they `git fetch` while I'm working? I often put all sorts of things in the code that I don't want to have committed, ranging from harmless (a bunch of personal comments or `IO.puts()`), to very important (API keys and such that I'm testing with. I always move them to env vars before committing but for first-pass testing to prove the concept I "hardcode" them at first).[1] 2. Similar to "how does it look to others," what sort of burden does "all operations you perform in the repo are recorded, along with a snapshot of the repo state after the operation" put on the git backend? If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so I can easily run `./mycode video.mp4`, does that whole thing get committed, potentially every time it changes? That could easily turn into a 40GB set of changes.[1] 3. Do you have to use the jj backend to get all the feature? For example, with a git backend could you get the two things mentioned above and also "Conflicts can be recorded in commits" as well? A quick section in the README.md about which features require the jj backend instead of git would be super helpful, and if written well could answer all of the questions above. To sum up my comment in a TL;DR: To really sell me on a project like this it has to work with git, and being able to quickly tell which features I can use with git, would make this substantially more interesting to me. [1]: Related: https://xkcd.com/1172/ https://xkcd.com/1172/
- martinvonz 5y ago
  > For example, "when the working copy is automatically committed," where does it go? It becomes a regular git commit with a git ref called something like `refs/jj/keep/9f1a0fb0-a0aa-4a4b-922f-d6d48687996a` pointing to it (to prevent GC). It won't get fetched or pushed by default, except with `--mirror`, I think. > If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so I can easily run `./mycode video.mp4` Yes! You'll have to more diligent about keeping your .gitignore (or .git/info/exclude, etc) file updated. I plan to add commands for fixing such mistakes by forgetting the commit. > Do you have to use the jj backend to get all the feature? Nope, conflicts work with the git backend as well. https://github.com/martinvonz/jj/blob/main/docs/git-compatibility.md#format-mapping-details https://github.com/martinvonz/jj/blob/main/docs/git-compatib... has some info. > To sum up my comment in a TL;DR: To really sell me on a project like this it has to work with git, and being able to quickly tell which features I can use with git, would make this substantially more interesting to me. Makes sense. Thanks for the suggestion! I'll put it on my TODO list.
kyrra 5y ago
For those that didn't look, this is 100% rust.
- martinvonz 5y ago
  Note, though, that it depends on libgit2 (which is written in C). (As pointed out by someone in https://github.com/martinvonz/jj/issues/56 https://github.com/martinvonz/jj/issues/56.)
- tonetheman 5y ago
- tuwtuwtuwtuw 5y ago
  Seems irrelevant to me. Why do you care about the language choice?
  - KerrAvon 5y ago
    On the negative side: In some environments it’s a hurdle to build programs in Rust. On the positive side: It signifies a certain likelihood of memory and data safety that you won’t get in most other languages.
  - ccbccccbbcccbb 5y ago
    Because it's trendy to praise brushes instead of paintings, vinyl pressing quality instead of music, and languages instead of software these days. Jean Baudrillard would call it another level of simulation.
  - binarypaean 5y ago
    Language matters quite a bit to those considering contributing. It also provides some context for expectations about performance and reliability thanks to language idioms, features and culture.
    - detaro 5y ago
      But the info is right on the linked page. Somehow I don't think people who haven't even followed the submission link aren't the ones to worry about yet for "potential contributor".
hinkley 5y ago
“Powerful” has become to me a shibboleth for people who are full of it. I can’t recall the last time a coworker who liked things because they were powerful didn’t end up being untrustworthy. Even dangerous. It’s like nobody remembers the Principle of Least Power. That said, I will take someone obsessed with “powerful” over “flexible” any day of the week.
- kjeetgill 5y ago
  Hm, I guess for tools like this I always read "powerful" as "flexible" - as in: this tools has strictly more power/capabilities making it more flexible. In terms of "dev tool marketing speak" I guess it's the opposite of "robust" meaning: fewer features that are less likely to break on you.
  - hinkley 5y ago
    The only flexible tool I use in the real world is the Leatherman, and that's for situations when I don't know what I'll need, or if I'll need it. For every other task I have a tool that is designed (sometimes quite well) for a set of tasks that includes the one at hand (see also Alton Brown, no single-purpose tools). The Leatherman is part of my EDC, along with an LED flashlight with some respectable lumens so I don't have to use my phone to see in the dark. In software this is known as the Unix Philosophy, but we violate it quite often, and call those tools 'powerful' or 'flexible'. Everything is a Swiss Army Knife all the time, and we aren't self-aware enough to see how consistently - and sometimes badly - we struggle with this. But you can't tell an addict they're an addict. They will fight you to the death about how they Don't Have a Problem.
skrebbel 5y ago
Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git. The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature branches lands in JJ I'm excited to switch.
- wcarss 5y ago
  > My team is totally PR based though so if/when doing (Git compatible) feature branches lands in JJ I'm excited to switch. I'm trying to find the part of the docs that refers to this functionality as missing but I can't -- does jj not have the ability to create, update, pull from, merge branches, etc?
  - intrepidhero 5y ago
    > For example, pull-request workflows currently require too many manual steps. Supported but not great I guess?
    - martinvonz 5y ago
      Yes, they are supported, and documented at https://github.com/martinvonz/jj/blob/main/docs/branches.md https://github.com/martinvonz/jj/blob/main/docs/branches.md. I need to document better how to use them for common workflows like GitHub PRs. FYI, here's one way to use them with GitHub PRs: 1. Create a fork via GitHub's web UI 2. Clone using the SSH protocol (`jj git clone git@github.com:...`) 3. Make your changes and "commit" (`jj close/commit`) 4. Create a branch pointing to the commit you just created (`jj branch my-feature -r @-`) 5. Push it to your fork (`jj git push`) So that doesn't seem too onerous, I guess? Maybe the "too many manual steps" are to clean up afterwards. I just tried it in a test repo and deleting the branch from the fork and then `jj git fetch` from there does delete the local branch, but it doesn't abandon the commits, so you need to run `jj abandon` on them if you don't want them anymore.
- 5y ago
blagie 5y ago
This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is the first project I've seen which appears to understand and respect /how/ and /why/ the git data model is so elegant.
- lillecarl 5y ago
  The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.
  - blagie 5y ago
    One of the many breakthroughs in git was precisely not being patch based. Being patch-based means that the tools for comparing versions are hard-coded into the data format. One of the major upsides of CVS->SVN, for example, was support for file moves. Simple issues like this weren't possible to fix without reworking the whole system. With a version-based model, how you compare them is determined by the user space, whether that's merges, or viewing history. Even compression isn't all that fundamental to much of anything; it's possible to implement underneath the system, eliminating whatever redundancy you want. With patch-based systems, all of that comes baked into the underlying representation. On a deeper level, this feeds into how git can be distributed, robust, yet very simple.
    - lillecarl 5y ago
      It also means cherry picking commits between branches prevents clean merging afterwards meaning you have to force yourself to keep branches short-lived. The patch graph pijul gives you doesn't have this issue. I'm not an expert, but when reading the Pijul blog it made a lot of sense for me.
      - blagie 5y ago
        No, that's mostly the fault of many bad decisions in the git user space. The data model is quite brilliant and quite general. It'd be possible to write a really good user space around the git data model if someone had the time and inclination. My personal gripes: * I like to commit every time I change a few lines of code. To have a clean version history, git requires me to rebase all of those commits. I'd like to have "major" and "minor" commits, which the git data model can support in several different ways (as a list, a tree, or DAG; I prefer the tree model). The user space makes anything like this incredibly painful. It encourages rewriting history, which is actually rather bad. * Large files are managed very, very badly. It's ironic since the git data model is ideal for things with large files. * Related, partial trees aren't really supported. This gives scaling issues. In many cases, I just want to work with a few files, or just the latest commit. Some of this is technically possible but practically painful enough to be not worthwhile. * Nested projects / submodules. Of those, only submodules might require changes to the underlying data model.
kuboble 5y ago
1) What are the advantages of using native backend as compared to git? 2) Are there any potential issues one has to be aware of when using jj contributing to git repository? I remember when I was the only team member using git-svn plugin my coworkers were confused when I svn-committed many commits at once with some of them breaking the time order of the svn history (as git-svn commits in svn were recorded with git timestamp and not the actual svn- commit timestamps)
- martinvonz 5y ago
  > 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend (https://github.com/martinvonz/jj/issues/27 https://github.com/martinvonz/jj/issues/27). Disadvantages include not being able to interact with git repo and performance problems (both size and speed). I should add a note about this to the README. The backend exists mostly to prove that it's possible and to make sure that the backend API doesn't become tied to Git. > 2) Are there any potential issues one has to be aware of when using jj contributing to git repository? The main one is that you should avoid pushing commits with conflicts. It won't corrupt the remote repo, but git clients won't know what to do with the conflicted files. The fix is to fix the conflict and force push the conflict-free commit. I'll file a bug to prevent pushing commits with conflicts.
  - krick 5y ago
    If we ignore the UI level stuff, like doing something by default when you switch to another branch, etc — is it in any way "smarter" than git? For example, are there situations, when I couldn't reorder my commits when doing git rebase -i without resolving some conflicts manually, while jj would be able to correctly handle them for me?
    - martinvonz 5y ago
      Yes and no. For example, if you reorder two commits, the new child commit will never have conflicts even if the parent had conflicts. That's because the changes from both original commits still apply afterwards. Similarly, if you rebase a commit and it results on conflicts, you can then rebase it back and the conflicts will go away. See the demo at https://asciinema.org/a/HqYA9SL2tzarPAErpYs684GGR https://asciinema.org/a/HqYA9SL2tzarPAErpYs684GGR
danbmil99 5y ago
Does it support lfs, or deal with large binary assets in some other way?
- martinvonz 5y ago
  No, there's no particular support for large files yet.
BiteCode_dev 5y ago
" It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts)." That's really interesting. Having to manage stashes is annoying.
- halfdan 5y ago
  Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-worktree/ https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
  - CorrectHorseBat 5y ago
    What is the advantage of using worktrees over another checkout in another folder?
    - 0xdky 5y ago
      You will need a full repository in other directory to checkout and this will waste storage unless you share objects via alternate.
    - ossusermivami 5y ago
      Optimizations and management really
    - halfdan 5y ago
      Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
      - cortesoft 5y ago
        Why would you lose that ability? You can just pull from the other checkout as an upstream, right?
jjthrowaway 5y ago
It would be nice if this were in nixpkgs, it's a pain to manage all the different language environments and it would save me from trying to get it to compile. Right now error[E0554]: `#![feature]` may not be used on the stable release channel --> lib/src/lib.rs:15:12 | 15 | #![feature(assert_matches)] |
- gmfawcett 5y ago
  If you get it working, please share a flake. :)
  - martinvonz 5y ago
    I filed https://github.com/martinvonz/jj/issues/61 https://github.com/martinvonz/jj/issues/61 about having Nix packages. I should learn about Nix packaging some day, but I'd appreciate any help I can get.
    - martinvonz 5y ago
      FYI, there was an update on that issue saying that they're going to create an overlay tomorrow.
      - gmfawcett 5y ago
        Awesome! Thanks for sharing the update.
adamnemecek 5y ago
Rust has truly reinvigorated these types of tools.
habitue 5y ago
I like that this is not "a dvcs written in rust" but rather "a dvcs with these awesome improvements over git." which incidentally happens to be written in rust because of course it's the right language for this.
- ParetoOptimal 5y ago
  I was really hoping it was implemented in Rust as I read the Readme on mobile and was happy to see a cargo.lock after clicking 'view code'.
qbasic_forever 5y ago
That's very cool to have support for rsync/dropbox collaboration of the repo files. I'm always sad that there isn't a maintained p2p git implementation anymore. I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it.
- CRConrad 5y ago
  > there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?
  - NateEag 5y ago
    As one who has set up skunkworks git boxes before, I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network. You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient. And if you settle on sharing one central box as the canonical node (which IMO is the right answer), you're no longer truly using a distributed system - it's a de facto centralized system.
    - qbasic_forever 5y ago
      Exactly, syncthing has flawless p2p discovery and networking/sharing of files. Being able to put a git bare repo effectively on a syncthing share would be super convenient for small private collaboration. Tailscale might be an option to make a bunch of local git repos all start pushing/pulling, but it has some headaches too and isn't really designed for opening up small single services.
    - CRConrad 5y ago
      > I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network. Ah, OK, gotcha. Thanks! > You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient. Yeah. But fortunately not all that much of a hassle for a small(ish) dev team. > And if you settle on sharing one central box as the canonical node (which IMO is the right answer), Yeah, we called it "the Dev server". :-) > you're no longer truly using a distributed system - it's a de facto centralized system. But in a corporate (or even Open Source project?) environment, The Powers That Be probably want that kind of / that much centralisation anyway.
em-bee 5y ago
jujutsu looks interesting, but one thing that i find missing from git is historical branch tracking. once two branches are merged, git does not tell me which series of commits used to belong to which branch. i can't check out main from two weeks ago if a merge happened in the meantime because that information is lost. i fear to add such a feature additional information would need to be stored in the git repo itself which would require a change to git
- Too 5y ago
  Git has the concept and knowledge of which side a merge came from. A commit having multiple parents (a merge commit) maintains the order of those parents within the commit. The branch names are famously lost, but by convention you can say that the first parent should always be the main branch. As with all other git things, the ux for this feature isn’t the best and it’s use varies wildly across tools and organizations. To view the main branch log only you have to pass arcane -—left-only flags into git log. Some people don’t know the difference of merging from branch to main vs the other way around, end result looks the same right. One such mistake messes up the history.
  - em-bee 5y ago
    that's the problem with git. it is powerful, but some things are just not practical. if i have to be careful how i merge then that's not user friendly. on the other hand, adding a field that stores the name of the branch at commit time would be almost trivial programmatically. and it would enable a much more user friendly interface.
- joseph8th 5y ago
  I don't need to repeat that Git has terrible UI, but you can get this "history" with `git merge --no-ff <MYBRANCH>` (no fast-forward). In fact, it's a pretty common branch-based flow. Our team pushes feature branches to remote, where they are vetted by QA, and we have a chance for review. When pulling changes into any branch, we always `git pull --rebase`. When merging feature branches, we always `--no-ff`. For small, local merges, we don't use `--no-ff` because it's useless noise. But if someone forgets out of habit... Oh well. I spend on average 0.000000001% of my time going through git log. And when I do, I tell it to show as a tree
jayd16 5y ago
> Entire repo is under version control I wonder how this works out for large files and cleaning them up.
- martinvonz 5y ago
  I doesn't work very well yet. See https://news.ycombinator.com/item?id=30399554 https://news.ycombinator.com/item?id=30399554.
CGamesPlay 5y ago
Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for no reason. I don't think I like that behavior, to be honest. Is this a requirement of any of the other unique features? Could this be turned off, or modified to be an explicit operation? [append] To be clear, the fact that it's `jj st` is actually a big part of the problem for me: this is the command I use to figure out what to put into my `.gitignore` in the first place! I don't think that any of the "read-only" commands should be making these kind of changes.
- bitcharmer 5y ago
  Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.
  - rileymat2 5y ago
    Have used node.js, I find this, conceptually, much more simple to trace through than search paths. Of course there are major cons.
  - Too 5y ago
    This is the default behavior of npm. The most popular package manager on the planet. It might not be technically the most superior way to do things, but given the widespread use, tooling around it need to be compatible.
    - IceDane 5y ago
      It puts those deps in your source tree, sure, but no one advocates committing them to your repository except in few specific scenarios. This kind of thing is also pretty much standard for most programming languages today.
giovannibonetti 5y ago
> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj". Yeah, it's just a coincidence that the world Jujutsu means magic in japanese (呪術)
deleted 5y ago
[deleted]
uses 5y ago
Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly manage the equivalent of .gitignore? What am I misunderstanding about the benefits of how this works?
- TillE 5y ago
  There are already popular Git GUIs like GitHub Desktop which abstract away the staging area. It's also how basically every other VCS works. Yeah, you should have an appropriately comprehensive .gitignore file, that's good practice in any case.
- markstos 5y ago
  You are too brainwashed by git.:) The bigger picture is that the project is trying to provide a better interface on top of the existing git data store. As someone who used darcs for a major project before Git dominated DVCS, there are much better user interfaces than what Git offers, and attempts to improve upon Git is a diversity to encourage. Unlike picking your own text editor, a whole team has to agree about the choice of DVCS, making it harder to try new ones. The beauty of a solution with a Git-compatible data store is it allows some people on the team to experiment with it while still collaborating with people using Git.
- krick 5y ago
  Your phrasing makes me think if I'm just too brainwashed by git as well, but, yeah, I wouldn't want anything to be added by default at all. While working I do all kinds of stuff I'm not going to commit, like debug statements and rough sketches, maybe some temporary scripts. And even though I do usually glance over diffs in the end, I don't really read them: that is, even if I did, it's not really my thoughts I see on the screen at that point, I'm as likely to notice mistakes there as I am in somebody else's code, if not less. When I'm adding a change, on the contrary, it's something I wrote minutes to seconds ago, I know what's in that code, and by adding that I'm kind of making a statement that this wasn't some random bullshit I do with the code, but something I intend to keep (even if later I'll completely change that while interactively rebasing or something like that). On the other hand, I didn't complain that much back in the day when I was using SVN. But I feel like my current workflow that employs most unique features of git is actually much better. Basically, horribly inconsistent CLI is the only complaint I have about git.
lostintangent 5y ago
This is awesome! And it’s so exciting to see folks investing energy into this problem space. Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?
- martinvonz 5y ago
  Good question. You're right on both guesses. One reason is that I want to make sure the API works well enough that it's easy to replace the backend. The current native backend is called `local_store` because it stores files locally (just like the Git backend does). I want to be able to add another backend that fetches objects from a remote instead (and caches them locally), although another option is to hide that part inside the backend like Git does with its partial clone support. I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet.
  - ParetoOptimal 5y ago
    > I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet. Awesome, that would enable a realistic no-risk path to adoption for most projects: - trying jujutsu on work codebase - if useful, tell a coworker and maybe they try it - present internally about pros - team tries and agrees its better, adopts it - after some months confidence is built, give a presentation on features you could get with jujutsu native backend, gauge interests\worth
joshuamorton 5y ago
Am I right to say that the working-copy-as-commit and undo-functionality features are inspired by piper? Mighty neat to see those make it to a normalish vcs.
- martinvonz 5y ago
  I'm not sure if I'm allowed to say whether Piper has those features, but since you seem to be a Googler, you probably know (or can find out) :) I suppose I can still tell you that the features were not inspired by Piper without revealing whether Piper has them :)
mstaoru 5y ago
Great work! Just FYI, in Chinese JJ is a way to refer to male reproductive organs.
ArtixFox 5y ago
oh cmon u cant trick me like that! i thought jujutsu kaisen was on hn
user-the-name 5y ago
I can't find it mentioned anywhere, but does jj support submodules? And does it make them actually work, unlike the broken mess git has? This is the biggest thing keeping me using mercurial, the fact that it has subrepos that work.
- iveqy 5y ago
  What do you think is broken with git submodules?
  - user-the-name 5y ago
    Everything? The default state after checking out a git project with submodules is for them to be in the wrong state! Keeping the state of submodules and the main repo in sync is a complete shambles. Try mercurial to see how to do it correctly.
ParetoOptimal 5y ago
I've long wished Pijul had a git backend because I think it might be superior but strongly feel the only way it could get mass adoption even if it's truly better is if people could just try it on their git repos like this. Removing the "convince my team to move away from git" part of a better DVCS could make jujutsu very popular. Or other git compatible spinoffs could be made that follow this approach and explore other design spaces.
daniel-cussen 5y ago
I hope this popularizes the correct spelling of Jujutsu.
rhabarba 5y ago
Finally! Another VCS!
- radlad 5y ago
  I think the network effect that Got has is one of the biggest reasons no other VCS has succeeded at user adoption in recent years. By allowing a Git backend to use the Jujutsu frontend it could develop a following.
lcall 5y ago
For comparison, another simpler (somewhat?) git-compatible client called "game of trees" or got (about which I know to little to compare/contrast well): https://gameoftrees.org/ https://gameoftrees.org/ .
ofrzeta 5y ago
It's amazing what some people can do in 20% of their work time.

568 points by rolisz 5y ago

I’m curious to know if this has any similarities with fossil (https://fossil-scm.org/ https://fossil-scm.org/ ). If it does, it would be nice to see that in the documentation.

throwaway81523 5y ago
Fossil is ideologically different, it wants to preserve every artifact, no rebasing allowed.
- cryptonector 5y ago
  That Fossil doesn't support rebase is a fiction, since it supports cherry-pick. All that's missing is a script around cherry-pick, which is all rebase is.

kazinator 5y ago

In git you can reorder any sequence of commits without any conflicts. Howwever, there is no nice "porcelain" for it. The basis for it is the read-tree command. In git, every commit is a snapshot and not a delta. (Repeat that three times.) Any arbitrary snapshots of files can be arranged into a git history. They don't even have to be related. We could take a tarball of GCC, and make that the first commit. Then a tarball of Clang and make that the second commit. The read-tree command will read any commit's state into the index, and from there you can make a commit out of it. To reorder some N commits you're looking at, save all of their hashes somewhere, and then rewind the branch: git reset --hard HEAD~N. Then use git read-tree to read those hashes in whatever order you want, committing them one by one. To reuse their commit messages you have to use commit -C <hash>, though most them likely don't make any sense, because the text of commit messages usually talks about changes between a commit and its main parent. What will happen is that your history now as N commits which represent the same states as the N you had there before, in a different order. For instance if you reverse them, then the oldest commit has all the features (is the same code baseline) as what the newest HEAD was previously. And then the subsequent child commits basically remove all the changes that were made, so the latest now looks like what the N-th looked like. How I sometimes use this: Suppose I made a fairly complex change that I would like to break up so that it is presented as a sequence of two or more states of the code. There are cases when the following workflow is easy: first I make a commit out of the changes. One commit with everything. That commit is what I want the final state to look like. Then I revert some of the changes to produce the state before that state. If I have mostly been adding things, this might consist of just deleting them. Or I can do a git reset --patch HEAD^ to selectively revert. I commit this penultimate state. Then repeat the process: revert some more changes from that one, commit and so on, as many times as I see fit. So what I end up with is the states of the code I want to present as a history, but exactly in the wrong order. Using "git rebase -i" doesn't work nicely; there are ugly conflicts, and some of them have to be encountered twice. Here is where the git read-tree trick comes into play: I simply reverse those exact states of the code to put them in the right order on the branch. After that I might do a rebase -i just to reword the commit messages to frame the code states from the POV of being changes from their parents. You might think: why not just "git commit --patch" from the original working state to produce commits in order. The reason is that doesn't always make sense. For that you had to remember to make the commit as you were working. Because say you refactored something and then made a change. You can't easily do a "git commit --patch" which separates the refactoring from the change. Sure, if you do the refactoring and then a commit, and then make the change, you are good. But suppose you've conflated them already; now what? You can commit everything and then back out the changes that were done on top of the refactoring, and commit that. Then reorder the two states.

mastazi 5y ago
> In git, every commit is a snapshot and not a delta. I know this, but also I cannot reconcile this whit what happens when you cherry-pick a commit from another branch. I'm confused because cherry-pick really seems to be taking out the delta not the snapshot. I'm thinking that cherry-pick takes that commit and makes a diff with its parent and then that's what you get when you call it. Is it how it works behind the scenes? I'm also thinking that the fact that each commit has at least one parent means that, conceptually, we can use it as if it was a delta (at least in the case of commit with one parent only), if you get what I mean. EDIT: I'm not familiar with the internals of Git, just a user. Commenting out of curiosity.
- kazinator 5y ago
  When you cherry-pick a commit from another branch, it's not doing anything like a read-tree to make your current work look like that commit's snapshot state. It's doing something like three-way merge between that commit, your baseline and a common ancestor (I'm guessing: the same one that would be identified by git merge-base <hash0> <hash1>.) That's why cherry-pick identifies conflicts. A cherry-pick deos not just do a diff with its parent 0 and then patch it onto your work. In many cases, that wouldn't work because that's not a three-way-merge, but a two-way merge, which has disadvantages. However: there may be situations when the commits are so distant, it might make sense just to turn that one into a patch and work the patch onto your baseline. Even if that needs manual work, it can be simpler. You will only get conflicts (patch hunk rejects in that case) that are relevant to that change. I've had lots of experience working with patch stacks (both before and after Quilt was introduced to make that a bit easier) so I'm comfortable migrating patches from one code base to another without a three-way-diff process within version control.
  - mastazi 5y ago
    Yes, I agree about distant commits and turning it into a patch. Thank you for explaining the three-way merge between baseline, commit and common ancestor, makes sense.
  - 5y ago

mdaniel 5y ago

That's quite impressive, congratulations! The git comparison docs have: > Start working on a new change based on the <main> branch -- jj co main Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? I actually can't tell from so deep in my "git Stockholm syndrome" whether that distinction is really hard on new users or not, but the fact that git expended the energy meant they thought it was meaningful And, do you have plans on supporting signed commits, either via gpg or the newfound SSH key signing? I'm super excited to try out the conflict resolution mechanism, because that's a major painpoint for my long-lived PR branches

martinvonz 5y ago
Thanks! > Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? Actually, isn't "restore" for file operations? My impression was that everyone agrees that `git checkout` does too many different things. In particular, it's both for switching branches and for restoring file content. So they added the new `git switch` and `git restore` with limited scope. I strongly suspect that they would have used `git checkout` for the former if that wasn't already taken by the existing command. > And, do you have plans on supporting signed commits, either via gpg or the newfound SSH key signing? No, that's not something I've even started thinking about. I'll have to read up on how it works in Git first. Patches welcome, though :) > I'm super excited to try out the conflict resolution mechanism, because that's a major painpoint for my long-lived PR branches You mean so you can continuously rebase them without having to resolve conflicts right away? Yes, that's one of the benefits of first-class conflicts. Another benefit, which took me a long time to realize how useful it is, is the auto-rebase feature.
- mdaniel 5y ago
  > No, that's not something I've even started thinking about. I'll have to read up on how it works in Git first. Patches welcome, though :) I opened an issue and provided links to the docs, and a link to the current way that git implements it: https://github.com/martinvonz/jj/issues/58 https://github.com/martinvonz/jj/issues/58 As I was trying to find the correct command in jj for where to add the new argument, I realized that this may not play nice-nice with jj's commit-everything model, so I'm actually prepared for the issue to be closed WONTFIX :-) As for the patches welcome part, I notice that the Google CLA bot is on your repo. While I do have the CLA signed for my Gmail address, it seemed like some major tomfoolery to try and add my current github email address (and the one which backs my GPG key, to bring this full circle!) to the existing CLA process. Do you intend to keep that CLA mechanism in place, or was it just an oversight?

jareds 5y ago

This looks interesting and I'm glad to see that people are not viewing SCM as a solved issue. While I don't think I'd use this on professional projects yet I'm interested at looking at this for personal projects since I can use the Git back-end and continue to use Github to host my code. I feel like Git has become such a DeFacto standard that nothing is going to replace it any time soon. I've been programming for long enough to remember feeling the same way about SVN though so I assume something will eventually supplant Git.

freedomben 5y ago
I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provides): if I'm working simultaneously on two different branches (for example one branch is a bug fix that requires 20 minutes to build and deploy before I can test it, so I work on other things while it's running), I often have two different checkouts so I can (mostly) avoid having to git stash. That said though, you are probably right something will eventually supplant git. It would be arrogant to think that my failure to imagine something better means there isn't anything.
- Hendrikto 5y ago
  What you are describing sounds as if you want worktrees: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
  - freedomben 5y ago
    Whoa, thank you! That does look like the answer!
- jeltz 5y ago
  I totally agree. Back when I used Subversion it felt to me like there obviously must be a better way to version control and that the tool got in my way all the time. Git on the other hand almost always can solve my problems and while some things could be improved (confusing UX, a bit too complex, plus bad handling of conflicts) it is much closer to the right tool for VCS than Subversion ever was.

mberning 5y ago

Congrats and good luck. Git desperately needs a radically simplified and radically consistent set of porcelain interfaces.

cryptonector 5y ago

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. > The working copy is automatically committed Right, so, the reason the index is powerful is that I get to do `git add -e`, `git commit`, and repeat until I'm done or ready to throw remaining changes away. I very much want the index / workspace distinction. > Automatic rebase > Comprehensive support for rewriting history This is very welcome. At the very least this confirms something important: the fallacious argument that "rebase rewrites history, so it's eeeevil" is finally dead.

yjftsjthsd-h 5y ago
If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?
- bonzini 5y ago
  The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.
  - masklinn 5y ago
    > You do that with a sequence of "git add -p" and "git commit" commands. You can do that with git commit -p.
    - bonzini 5y ago
      True but there's usually a "git diff --staged" in the middle to check what I am committing.

swagonomixxx 5y ago

> A Git-compatible DVCS that is both simple and powerful We all know the dig here - Git is not simple. Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago. Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly because version control _is_ complex. I also don't agree that Git is hard to use. I feel it is an odd goal to try to make everything - even tools that experts use - simple to use, when they are fundamentally not simple. I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.

martinvonz 5y ago
> I feel like Git is sufficiently complex - no more than it needs to be and certainly not less. Perhaps the biggest mistake (IMO) was to expose the index to the user. I happened to just watch https://www.youtube.com/watch?v=31XZYMjg93o https://www.youtube.com/watch?v=31XZYMjg93o (by the person behind Gitless). They explain the issues well there.
- KerrAvon 5y ago
  I haven’t watched that video, but I agree — the index is one of the biggest hurdles to making git easy to understand and use for newcomers. It’s not hard to explain the fundamental model of how git works — it’s hard to explain the UI, and it’s hard to explain the index. If you remove the index, you’re only working with commits, and that simplifies the UI enormously.
- hinkley 5y ago
  I'm gonna watch this video. What's been bugging me for a long time, as someone who didn't quite get to see all of the supposed ugliness of Subversion (which by description alone sounds an awful lot like the rerere situation with Git, which I have). It really feels to me like a commit identifier should be the combination of a monotonically increasing number and a hash of the content, rather than an either-or. If I merge or rebase branches in git, I lose the index, just as I would in subversion. But at least in svn I have some notion of how far back commit 12345 is in the tree. ac4def2 could be HEAD or four years ago.

dark-star 5y ago

git is already very simple, at least for the 95% of use-cases that I need. add, commit, checkout, push, pull.... maybe a branch and merge here and there, but that's it. Of course I cannot remember how exactly the "git rebase" command works and have to look it up every time, same as all those switches to the "simpler" commands. I guess it all depends on what you need. Python looks really complicated too, if you start by browsing the function and class reference. But for someone starting to learn programming, it is apparently pretty easy (or so I've heard)

freedomben 5y ago

This looks like an interesting project, and I'm glad that people are still thinking about how to improve on version control. That said, building a version control system seems like a problem similar to a social network: the network affect causes an enormous amount of friction. i.e. most people don't want to use it until other people are using it. A vicious cycle. The fact that it's compatible with git as a backend is really great though, and is probably the key to driving adoption. However I have several immediate thoughts that come to mind that cause me hesitancy. Answers in the README.md would be super helpful for marketing to me (and deep apology if it's there and I missed it): 1. How does it look to others working on the repo using just git? For example, "when the working copy is automatically committed," where does it go? is there a remote branch that someone could see if they `git fetch` while I'm working? I often put all sorts of things in the code that I don't want to have committed, ranging from harmless (a bunch of personal comments or `IO.puts()`), to very important (API keys and such that I'm testing with. I always move them to env vars before committing but for first-pass testing to prove the concept I "hardcode" them at first).[1] 2. Similar to "how does it look to others," what sort of burden does "all operations you perform in the repo are recorded, along with a snapshot of the repo state after the operation" put on the git backend? If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so I can easily run `./mycode video.mp4`, does that whole thing get committed, potentially every time it changes? That could easily turn into a 40GB set of changes.[1] 3. Do you have to use the jj backend to get all the feature? For example, with a git backend could you get the two things mentioned above and also "Conflicts can be recorded in commits" as well? A quick section in the README.md about which features require the jj backend instead of git would be super helpful, and if written well could answer all of the questions above. To sum up my comment in a TL;DR: To really sell me on a project like this it has to work with git, and being able to quickly tell which features I can use with git, would make this substantially more interesting to me. [1]: Related: https://xkcd.com/1172/ https://xkcd.com/1172/

martinvonz 5y ago
> For example, "when the working copy is automatically committed," where does it go? It becomes a regular git commit with a git ref called something like `refs/jj/keep/9f1a0fb0-a0aa-4a4b-922f-d6d48687996a` pointing to it (to prevent GC). It won't get fetched or pushed by default, except with `--mirror`, I think. > If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so I can easily run `./mycode video.mp4` Yes! You'll have to more diligent about keeping your .gitignore (or .git/info/exclude, etc) file updated. I plan to add commands for fixing such mistakes by forgetting the commit. > Do you have to use the jj backend to get all the feature? Nope, conflicts work with the git backend as well. https://github.com/martinvonz/jj/blob/main/docs/git-compatibility.md#format-mapping-details https://github.com/martinvonz/jj/blob/main/docs/git-compatib... has some info. > To sum up my comment in a TL;DR: To really sell me on a project like this it has to work with git, and being able to quickly tell which features I can use with git, would make this substantially more interesting to me. Makes sense. Thanks for the suggestion! I'll put it on my TODO list.

kyrra 5y ago

For those that didn't look, this is 100% rust.

martinvonz 5y ago
Note, though, that it depends on libgit2 (which is written in C). (As pointed out by someone in https://github.com/martinvonz/jj/issues/56 https://github.com/martinvonz/jj/issues/56.)
tonetheman 5y ago
tuwtuwtuwtuw 5y ago
Seems irrelevant to me. Why do you care about the language choice?
- KerrAvon 5y ago
  On the negative side: In some environments it’s a hurdle to build programs in Rust. On the positive side: It signifies a certain likelihood of memory and data safety that you won’t get in most other languages.
- ccbccccbbcccbb 5y ago
  Because it's trendy to praise brushes instead of paintings, vinyl pressing quality instead of music, and languages instead of software these days. Jean Baudrillard would call it another level of simulation.
- binarypaean 5y ago
  Language matters quite a bit to those considering contributing. It also provides some context for expectations about performance and reliability thanks to language idioms, features and culture.
  - detaro 5y ago
    But the info is right on the linked page. Somehow I don't think people who haven't even followed the submission link aren't the ones to worry about yet for "potential contributor".

hinkley 5y ago

“Powerful” has become to me a shibboleth for people who are full of it. I can’t recall the last time a coworker who liked things because they were powerful didn’t end up being untrustworthy. Even dangerous. It’s like nobody remembers the Principle of Least Power. That said, I will take someone obsessed with “powerful” over “flexible” any day of the week.

kjeetgill 5y ago
Hm, I guess for tools like this I always read "powerful" as "flexible" - as in: this tools has strictly more power/capabilities making it more flexible. In terms of "dev tool marketing speak" I guess it's the opposite of "robust" meaning: fewer features that are less likely to break on you.
- hinkley 5y ago
  The only flexible tool I use in the real world is the Leatherman, and that's for situations when I don't know what I'll need, or if I'll need it. For every other task I have a tool that is designed (sometimes quite well) for a set of tasks that includes the one at hand (see also Alton Brown, no single-purpose tools). The Leatherman is part of my EDC, along with an LED flashlight with some respectable lumens so I don't have to use my phone to see in the dark. In software this is known as the Unix Philosophy, but we violate it quite often, and call those tools 'powerful' or 'flexible'. Everything is a Swiss Army Knife all the time, and we aren't self-aware enough to see how consistently - and sometimes badly - we struggle with this. But you can't tell an addict they're an addict. They will fight you to the death about how they Don't Have a Problem.

skrebbel 5y ago

Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git. The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature branches lands in JJ I'm excited to switch.

wcarss 5y ago
> My team is totally PR based though so if/when doing (Git compatible) feature branches lands in JJ I'm excited to switch. I'm trying to find the part of the docs that refers to this functionality as missing but I can't -- does jj not have the ability to create, update, pull from, merge branches, etc?
- intrepidhero 5y ago
  > For example, pull-request workflows currently require too many manual steps. Supported but not great I guess?
  - martinvonz 5y ago
    Yes, they are supported, and documented at https://github.com/martinvonz/jj/blob/main/docs/branches.md https://github.com/martinvonz/jj/blob/main/docs/branches.md. I need to document better how to use them for common workflows like GitHub PRs. FYI, here's one way to use them with GitHub PRs: 1. Create a fork via GitHub's web UI 2. Clone using the SSH protocol (`jj git clone git@github.com:...`) 3. Make your changes and "commit" (`jj close/commit`) 4. Create a branch pointing to the commit you just created (`jj branch my-feature -r @-`) 5. Push it to your fork (`jj git push`) So that doesn't seem too onerous, I guess? Maybe the "too many manual steps" are to clean up afterwards. I just tried it in a test repo and deleting the branch from the fork and then `jj git fetch` from there does delete the local branch, but it doesn't abandon the commits, so you need to run `jj abandon` on them if you don't want them anymore.
5y ago

blagie 5y ago

This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is the first project I've seen which appears to understand and respect /how/ and /why/ the git data model is so elegant.

lillecarl 5y ago
The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.
- blagie 5y ago
  One of the many breakthroughs in git was precisely not being patch based. Being patch-based means that the tools for comparing versions are hard-coded into the data format. One of the major upsides of CVS->SVN, for example, was support for file moves. Simple issues like this weren't possible to fix without reworking the whole system. With a version-based model, how you compare them is determined by the user space, whether that's merges, or viewing history. Even compression isn't all that fundamental to much of anything; it's possible to implement underneath the system, eliminating whatever redundancy you want. With patch-based systems, all of that comes baked into the underlying representation. On a deeper level, this feeds into how git can be distributed, robust, yet very simple.
  - lillecarl 5y ago
    It also means cherry picking commits between branches prevents clean merging afterwards meaning you have to force yourself to keep branches short-lived. The patch graph pijul gives you doesn't have this issue. I'm not an expert, but when reading the Pijul blog it made a lot of sense for me.
    - blagie 5y ago
      No, that's mostly the fault of many bad decisions in the git user space. The data model is quite brilliant and quite general. It'd be possible to write a really good user space around the git data model if someone had the time and inclination. My personal gripes: * I like to commit every time I change a few lines of code. To have a clean version history, git requires me to rebase all of those commits. I'd like to have "major" and "minor" commits, which the git data model can support in several different ways (as a list, a tree, or DAG; I prefer the tree model). The user space makes anything like this incredibly painful. It encourages rewriting history, which is actually rather bad. * Large files are managed very, very badly. It's ironic since the git data model is ideal for things with large files. * Related, partial trees aren't really supported. This gives scaling issues. In many cases, I just want to work with a few files, or just the latest commit. Some of this is technically possible but practically painful enough to be not worthwhile. * Nested projects / submodules. Of those, only submodules might require changes to the underlying data model.

kuboble 5y ago

1) What are the advantages of using native backend as compared to git? 2) Are there any potential issues one has to be aware of when using jj contributing to git repository? I remember when I was the only team member using git-svn plugin my coworkers were confused when I svn-committed many commits at once with some of them breaking the time order of the svn history (as git-svn commits in svn were recorded with git timestamp and not the actual svn- commit timestamps)

martinvonz 5y ago
> 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend (https://github.com/martinvonz/jj/issues/27 https://github.com/martinvonz/jj/issues/27). Disadvantages include not being able to interact with git repo and performance problems (both size and speed). I should add a note about this to the README. The backend exists mostly to prove that it's possible and to make sure that the backend API doesn't become tied to Git. > 2) Are there any potential issues one has to be aware of when using jj contributing to git repository? The main one is that you should avoid pushing commits with conflicts. It won't corrupt the remote repo, but git clients won't know what to do with the conflicted files. The fix is to fix the conflict and force push the conflict-free commit. I'll file a bug to prevent pushing commits with conflicts.
- krick 5y ago
  If we ignore the UI level stuff, like doing something by default when you switch to another branch, etc — is it in any way "smarter" than git? For example, are there situations, when I couldn't reorder my commits when doing git rebase -i without resolving some conflicts manually, while jj would be able to correctly handle them for me?
  - martinvonz 5y ago
    Yes and no. For example, if you reorder two commits, the new child commit will never have conflicts even if the parent had conflicts. That's because the changes from both original commits still apply afterwards. Similarly, if you rebase a commit and it results on conflicts, you can then rebase it back and the conflicts will go away. See the demo at https://asciinema.org/a/HqYA9SL2tzarPAErpYs684GGR https://asciinema.org/a/HqYA9SL2tzarPAErpYs684GGR

danbmil99 5y ago

Does it support lfs, or deal with large binary assets in some other way?

martinvonz 5y ago
No, there's no particular support for large files yet.

BiteCode_dev 5y ago

" It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts)." That's really interesting. Having to manage stashes is annoying.

halfdan 5y ago
Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-worktree/ https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
- CorrectHorseBat 5y ago
  What is the advantage of using worktrees over another checkout in another folder?
  - 0xdky 5y ago
    You will need a full repository in other directory to checkout and this will waste storage unless you share objects via alternate.
  - ossusermivami 5y ago
    Optimizations and management really
  - halfdan 5y ago
    Duplicate storage as already mentioned, but you will also lose the ability to merge / doff cross branches if you have separate checkouts.
    - cortesoft 5y ago
      Why would you lose that ability? You can just pull from the other checkout as an upstream, right?

jjthrowaway 5y ago

It would be nice if this were in nixpkgs, it's a pain to manage all the different language environments and it would save me from trying to get it to compile. Right now error[E0554]: `#![feature]` may not be used on the stable release channel --> lib/src/lib.rs:15:12 | 15 | #![feature(assert_matches)] |

gmfawcett 5y ago
If you get it working, please share a flake. :)
- martinvonz 5y ago
  I filed https://github.com/martinvonz/jj/issues/61 https://github.com/martinvonz/jj/issues/61 about having Nix packages. I should learn about Nix packaging some day, but I'd appreciate any help I can get.
  - martinvonz 5y ago
    FYI, there was an update on that issue saying that they're going to create an overlay tomorrow.
    - gmfawcett 5y ago
      Awesome! Thanks for sharing the update.

adamnemecek 5y ago

Rust has truly reinvigorated these types of tools.

habitue 5y ago

I like that this is not "a dvcs written in rust" but rather "a dvcs with these awesome improvements over git." which incidentally happens to be written in rust because of course it's the right language for this.

ParetoOptimal 5y ago
I was really hoping it was implemented in Rust as I read the Readme on mobile and was happy to see a cargo.lock after clicking 'view code'.

qbasic_forever 5y ago

That's very cool to have support for rsync/dropbox collaboration of the repo files. I'm always sad that there isn't a maintained p2p git implementation anymore. I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it.

CRConrad 5y ago
> there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?
- NateEag 5y ago
  As one who has set up skunkworks git boxes before, I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network. You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient. And if you settle on sharing one central box as the canonical node (which IMO is the right answer), you're no longer truly using a distributed system - it's a de facto centralized system.
  - qbasic_forever 5y ago
    Exactly, syncthing has flawless p2p discovery and networking/sharing of files. Being able to put a git bare repo effectively on a syncthing share would be super convenient for small private collaboration. Tailscale might be an option to make a bunch of local git repos all start pushing/pulling, but it has some headaches too and isn't really designed for opening up small single services.
  - CRConrad 5y ago
    > I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network. Ah, OK, gotcha. Thanks! > You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient. Yeah. But fortunately not all that much of a hassle for a small(ish) dev team. > And if you settle on sharing one central box as the canonical node (which IMO is the right answer), Yeah, we called it "the Dev server". :-) > you're no longer truly using a distributed system - it's a de facto centralized system. But in a corporate (or even Open Source project?) environment, The Powers That Be probably want that kind of / that much centralisation anyway.

em-bee 5y ago

jujutsu looks interesting, but one thing that i find missing from git is historical branch tracking. once two branches are merged, git does not tell me which series of commits used to belong to which branch. i can't check out main from two weeks ago if a merge happened in the meantime because that information is lost. i fear to add such a feature additional information would need to be stored in the git repo itself which would require a change to git

Too 5y ago
Git has the concept and knowledge of which side a merge came from. A commit having multiple parents (a merge commit) maintains the order of those parents within the commit. The branch names are famously lost, but by convention you can say that the first parent should always be the main branch. As with all other git things, the ux for this feature isn’t the best and it’s use varies wildly across tools and organizations. To view the main branch log only you have to pass arcane -—left-only flags into git log. Some people don’t know the difference of merging from branch to main vs the other way around, end result looks the same right. One such mistake messes up the history.
- em-bee 5y ago
  that's the problem with git. it is powerful, but some things are just not practical. if i have to be careful how i merge then that's not user friendly. on the other hand, adding a field that stores the name of the branch at commit time would be almost trivial programmatically. and it would enable a much more user friendly interface.
joseph8th 5y ago
I don't need to repeat that Git has terrible UI, but you can get this "history" with `git merge --no-ff <MYBRANCH>` (no fast-forward). In fact, it's a pretty common branch-based flow. Our team pushes feature branches to remote, where they are vetted by QA, and we have a chance for review. When pulling changes into any branch, we always `git pull --rebase`. When merging feature branches, we always `--no-ff`. For small, local merges, we don't use `--no-ff` because it's useless noise. But if someone forgets out of habit... Oh well. I spend on average 0.000000001% of my time going through git log. And when I do, I tell it to show as a tree

jayd16 5y ago

> Entire repo is under version control I wonder how this works out for large files and cleaning them up.

martinvonz 5y ago
I doesn't work very well yet. See https://news.ycombinator.com/item?id=30399554 https://news.ycombinator.com/item?id=30399554.

CGamesPlay 5y ago

Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for no reason. I don't think I like that behavior, to be honest. Is this a requirement of any of the other unique features? Could this be turned off, or modified to be an explicit operation? [append] To be clear, the fact that it's `jj st` is actually a big part of the problem for me: this is the command I use to figure out what to put into my `.gitignore` in the first place! I don't think that any of the "read-only" commands should be making these kind of changes.

bitcharmer 5y ago
Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.
- rileymat2 5y ago
  Have used node.js, I find this, conceptually, much more simple to trace through than search paths. Of course there are major cons.
- Too 5y ago
  This is the default behavior of npm. The most popular package manager on the planet. It might not be technically the most superior way to do things, but given the widespread use, tooling around it need to be compatible.
  - IceDane 5y ago
    It puts those deps in your source tree, sure, but no one advocates committing them to your repository except in few specific scenarios. This kind of thing is also pretty much standard for most programming languages today.

giovannibonetti 5y ago

> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj". Yeah, it's just a coincidence that the world Jujutsu means magic in japanese (呪術)

deleted 5y ago

[deleted]

uses 5y ago

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly manage the equivalent of .gitignore? What am I misunderstanding about the benefits of how this works?

TillE 5y ago
There are already popular Git GUIs like GitHub Desktop which abstract away the staging area. It's also how basically every other VCS works. Yeah, you should have an appropriately comprehensive .gitignore file, that's good practice in any case.
markstos 5y ago
You are too brainwashed by git.:) The bigger picture is that the project is trying to provide a better interface on top of the existing git data store. As someone who used darcs for a major project before Git dominated DVCS, there are much better user interfaces than what Git offers, and attempts to improve upon Git is a diversity to encourage. Unlike picking your own text editor, a whole team has to agree about the choice of DVCS, making it harder to try new ones. The beauty of a solution with a Git-compatible data store is it allows some people on the team to experiment with it while still collaborating with people using Git.
krick 5y ago
Your phrasing makes me think if I'm just too brainwashed by git as well, but, yeah, I wouldn't want anything to be added by default at all. While working I do all kinds of stuff I'm not going to commit, like debug statements and rough sketches, maybe some temporary scripts. And even though I do usually glance over diffs in the end, I don't really read them: that is, even if I did, it's not really my thoughts I see on the screen at that point, I'm as likely to notice mistakes there as I am in somebody else's code, if not less. When I'm adding a change, on the contrary, it's something I wrote minutes to seconds ago, I know what's in that code, and by adding that I'm kind of making a statement that this wasn't some random bullshit I do with the code, but something I intend to keep (even if later I'll completely change that while interactively rebasing or something like that). On the other hand, I didn't complain that much back in the day when I was using SVN. But I feel like my current workflow that employs most unique features of git is actually much better. Basically, horribly inconsistent CLI is the only complaint I have about git.

lostintangent 5y ago

This is awesome! And it’s so exciting to see folks investing energy into this problem space. Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?

martinvonz 5y ago
Good question. You're right on both guesses. One reason is that I want to make sure the API works well enough that it's easy to replace the backend. The current native backend is called `local_store` because it stores files locally (just like the Git backend does). I want to be able to add another backend that fetches objects from a remote instead (and caches them locally), although another option is to hide that part inside the backend like Git does with its partial clone support. I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet.
- ParetoOptimal 5y ago
  > I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet. Awesome, that would enable a realistic no-risk path to adoption for most projects: - trying jujutsu on work codebase - if useful, tell a coworker and maybe they try it - present internally about pros - team tries and agrees its better, adopts it - after some months confidence is built, give a presentation on features you could get with jujutsu native backend, gauge interests\worth

joshuamorton 5y ago

Am I right to say that the working-copy-as-commit and undo-functionality features are inspired by piper? Mighty neat to see those make it to a normalish vcs.

martinvonz 5y ago
I'm not sure if I'm allowed to say whether Piper has those features, but since you seem to be a Googler, you probably know (or can find out) :) I suppose I can still tell you that the features were not inspired by Piper without revealing whether Piper has them :)

mstaoru 5y ago

Great work! Just FYI, in Chinese JJ is a way to refer to male reproductive organs.

ArtixFox 5y ago

oh cmon u cant trick me like that! i thought jujutsu kaisen was on hn

user-the-name 5y ago

I can't find it mentioned anywhere, but does jj support submodules? And does it make them actually work, unlike the broken mess git has? This is the biggest thing keeping me using mercurial, the fact that it has subrepos that work.

iveqy 5y ago
What do you think is broken with git submodules?
- user-the-name 5y ago
  Everything? The default state after checking out a git project with submodules is for them to be in the wrong state! Keeping the state of submodules and the main repo in sync is a complete shambles. Try mercurial to see how to do it correctly.

ParetoOptimal 5y ago

I've long wished Pijul had a git backend because I think it might be superior but strongly feel the only way it could get mass adoption even if it's truly better is if people could just try it on their git repos like this. Removing the "convince my team to move away from git" part of a better DVCS could make jujutsu very popular. Or other git compatible spinoffs could be made that follow this approach and explore other design spaces.

daniel-cussen 5y ago

I hope this popularizes the correct spelling of Jujutsu.

rhabarba 5y ago

Finally! Another VCS!

radlad 5y ago
I think the network effect that Got has is one of the biggest reasons no other VCS has succeeded at user adoption in recent years. By allowing a Git backend to use the Jujutsu frontend it could develop a following.

lcall 5y ago

For comparison, another simpler (somewhat?) git-compatible client called "game of trees" or got (about which I know to little to compare/contrast well): https://gameoftrees.org/ https://gameoftrees.org/ .

ofrzeta 5y ago

It's amazing what some people can do in 20% of their work time.