9 ms·

Jujutsu: A Next Generation Replacement for Git

94 points by vincent_s 2y ago

keikobadthebad 2y ago
stgit...
- childintime 2y ago
  https://stacked-git.github.io/ https://stacked-git.github.io/
setheron 2y ago
Honestly nothing of substance here. Would be great to get a first hand account of jj in practice.
- chaychoong 2y ago
  I have a short blog post here that describes some of my basic workflows: https://blog.chay.dev/basic-jj-workflows https://blog.chay.dev/basic-jj-workflows
viraptor 2y ago
How do people work with jujutsu and hacks/secrets? Having no staging feels like a disaster magnet to me where things that should never be published have a chance to be saved and distributed by accident. I consistently have some temporary workarounds / scripts / credentials / logs hanging around my repos while I work on things. I think I'd have to change my approaches significantly to use this safely.
- xlii 2y ago
  In short commit is your stage. It’s expected that you look at the commits before you push, the same as you do with staging. If you’d just "commit -am" the results would be the same. And since a commit can branch you can have a multiple (conceptual) stages. Jujutsu respects gitignore but cannot be told to not track in-file changes. Annoying when your peers commit customization files into the repository.
- hoseja 2y ago
  Targeted to the always online generation that does this automatically, probably. Whips in the soul.
- 3523582908 2y ago
  I am a fan of the dev branch strategy [1], where I have a specific commit that holds all my customizations that I rebase off of. This blog post has it set up such that git automatically ignore pushing the dev commit, but I haven't really gotten that far yet. I just rebase my branch off current main when I'm ready to push. [1]: https://reasonablypolymorphic.com/blog/jj-strategy/index.html#the-dev-branch https://reasonablypolymorphic.com/blog/jj-strategy/index.htm...
- aseipp 2y ago
  Things like logs are just generally ignored in gitignore so they can just be there or whatever. In practice this hasn't been a huge problem for me. Hacks/workarounds/etc are actually pretty easy to handle and there are a couple strategies. The one I use is to use a merge commit. Let's say you have a patch P that you want to keep private (it hardcodes some build settings you like to use or whatever) and a patch A you want to work on. The base these changes are based off is B which is the upstream branch "main". Then, you create a merge between A and P, creating commit M, and your working copy (called @ or "at") sits on top: --> P --> / \ B (main) M --> @ \ / --> A --> And now, both `P` and `A` exist in your repository at the same time. Now, you can just use the `jj squash` command to take changes from `@` and put them inside either A or P, as you do your work, thus moving them "through" the merge commit M. These kinds of techniques where you move changes between commits are very common in Jujutsu so this is pretty natural once you get used to it. Note that you can also have `M = @`, i.e. the merge commit is the working copy itself. I prefer to keep the commit M separate and work "on top" of it like in the above graph, because you may solve a conflict between P and A, and M would be the correct place to put it, and you would want to keep it separate from everything else. A neat feature of this trick is that you can create a branch for change `A` and if you are sitting on top of `M`, and you run `jj git push`, then only `A` will be pushed and `P` will be ignored and left alone. In fact `P` will never be pushed unless you explicitly ask for it by creating the branch pointing to it. Nor is the merge commit ever pushed anywhere; it only exists so that you can have both changes available locally. I do this all the time these days in various forms, and in practice, the day-to-day stuff isn't terribly different than it is when you just leave things out of the staging area inside your working copy.
bdcravens 2y ago
While this is just a blog article, which is fine, I think the intended audience isn't sold on being told to run a couple of commands and install a mystery binary. (especially for those not already familiar with the Rust ecosystem and package manager) The actual project website is here: https://martinvonz.github.io/jj/latest/ https://martinvonz.github.io/jj/latest/ The repo is https://github.com/martinvonz/jj https://github.com/martinvonz/jj Note: the project author is a Googler, and it appears to be under the umbrella of Google/Alphabet, as a CLA is required: https://martinvonz.github.io/jj/latest/contributing/ https://martinvonz.github.io/jj/latest/contributing/
wodenokoto 2y ago
I’m as interested in the next git as much as the next guy, but this gives me no idea how I should or could work with jujutsu. Anonymous branches? How do I get back to my work? Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history? I have no impression of how this makes anything easier.
- yawaramin 2y ago
  I think this is just the hallmark of a new technology. Nobody understood how (or why) to use git when it first appeared either until people showed up who could communicate its benefits and UX really well.
  - ahartmetz 2y ago
    Git, though, has the somewhat unique problem that its UX does a particularly bad job of explaining itself. Git isn't difficult because of its mind-bending awesomeness, but because the UX sucks. I'm fine with it, thankyouverymuch, but it was rote learning and I watch beginners struggle.
- steveklabnik 2y ago
  > Anonymous branches? How do I get back to my work? I fully appreciate this question, as I was there too until I started working with anonymous branches. Here's some sample output from jj log: $ jj log --limit 5 @ pzoqtwuv steve@steveklabnik.com 2024-03-01 15:06:59.000 -06:00 9353442b │ added some cool new feature │ ◉ xrslwzvq steve@steveklabnik.com 2024-02-29 23:06:23.000 -06:00 a70d464c ├─╯ create hello and goodbye functions │ ◉ yykpmnuq steve@steveklabnik.com 2024-02-29 23:03:22.000 -06:00 210283e8 ├─╯ add better documentation ◉ ootnlvpt steve@steveklabnik.com 2024-02-28 23:26:44.000 -06:00 b5db7940 │ only print hello world ◉ nmptruqn steve@steveklabnik.com 2024-02-28 23:09:11.000 -06:00 90a2e97f │ refactor printing Here, we are working on change 'pzoqtwuv'. (@ means the working copy.) There are colors in the real CLI to make the differences more obvious, and to show you unique prefixes, so for example, you probably only need 'p' or 'pz' instead of 'pzoqtwuv' to uniquely identify the change. I'll use the full IDs since there's no syntax highlighting here. We have two anonymous branches here. They have the change IDs of 'xrslwzvq' and 'yykpmnuq'. The log output shows the summary line of their messages, so we can see "create hello and goodbye functions" on one branch, and "add better documentation" on the other. You don't need an additional branch name: the change ID is already there. If you want to add even more better documentation, 'jj new yykpmnuq' (or again, likely 'jj new yy' in practice) and you're off to the races. (jj new makes a new change off of the parent you specify.) That's all there is to it. We already have the commit messages and IDs, giving an additional identifier doesn't help that much. (And if you're in a larger repo with more outstanding branches, you can ask 'jj log' to show specific subsets of commits. It has a powerful DSL that lets you do so. For example, say you only want to see your commits, 'jj log -r 'mine()'' can do that for you.) > Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history? The simplest answer is "you put that stuff in your .gitignore and it never gets committed." That said, it is recognized that sometimes that is not possible or easy. See https://github.com/martinvonz/jj/issues/323 https://github.com/martinvonz/jj/issues/323 for the current discussion about how to maybe support alternatives here. See also https://news.ycombinator.com/item?id=40917149 https://news.ycombinator.com/item?id=40917149 > I have no impression of how this makes anything easier. My take on this is that jj has fewer but also more orthogonal concepts. Naming things is hard. I don't like to do it. Not needing to name branches is really nice, as I don't really lose anything by not naming them, and I no longer have to name them. With regards to some other stuff, the "auto commit of saved files" really means that jj turns two of git's concepts, commits and the index, into one concept: commits. How is that easier? Well, I don't need to learn two sets of tools for dealing with the index vs a commit. For example, git has two kinds of resets: hard and soft. This is because git needs to have two sets of behaviors to deal with both concepts here, as git reset is about changing the index but maybe or maybe not the working tree. All of these distinctions don't matter in jj, because it's all just commits, so you use regular old tools on commits for them.
lifeformed 2y ago
What I want with a new git is first class support for large binary files. It's essential in game dev, and the best solution seems to be git lfs, which has its own problems.
- reverius42 2y ago
  This is what we’re building https://xethub.com https://xethub.com for! It’s a git forge with better support for large files (using git-xet instead of git-lfs) and it’s designed to store source code and binary assets in the same repo. Disclaimer: I work at XetHub.
- martinvonz 2y ago
  I hope we'll be able to do better once we have an open-source storage backend that stores contents in a central database (like we do with Jujutsu at Google).
  - dastbe 2y ago
    is there any active work on an oss storage backend? any blockers in the jujutsu codebase to starting one?
    - martinvonz 2y ago
      I don't think anyone has started working on it. We would want a design doc first. Note that the solution probably involve a local daemon process for caching reads and optimistically accepting writes and then sending them to the server in the background. That's what we do for latency at Google. But that's just an optimization and can come after the server is done. If you're interested in working on it, it would help if you joined our Discord server.
snthpy 2y ago
I saw a youtube talk on this a year or two ago and it looked promising. I've been waiting to see more people take it up and sing its praises. This is the first HN post I've noticed since then. Any experiences of anyone trying it out and switching over to it?
- snthpy 2y ago
  I think this was the talk: https://youtu.be/bx_LGilOuE4?si=K7k0hqUmeXl8ULLf https://youtu.be/bx_LGilOuE4?si=K7k0hqUmeXl8ULLf I would like to know more about the first class conflict handling. That could potentially be useful for an application I have in mind but I need to understand the algorithms better. How does it compare to CRDTs or other merge strategies?
  - stouset 2y ago
    The easiest way to think about it is that merge conflicts aren't something that causes operations to be aborted like they are in git. If you have a merge conflict or a rebase, conflict markers are inserted and everything continues. You can quickly see any commits that have merge conflicts. If some operation introduced them, you can go edit that commit and fix them. When you do so, the fix propagates forward automagically to all descendant commits. The benefit here is that the operation you were trying to do fully completes and you're never ejected into an intermediate state where changes are dropped into your working copy and you're expected to fix it right here and now before anything else happens. You don't have to unwind everything because you screwed up an earlier conflict resolution since everything is stored in history; you just go back to the commit you want to fix, make a change, and then jump back to the later commit that still needed some work.
- 3523582908 2y ago
  It's been my daily driver for the last 3 months, and it's really amazing. Highly recommend trying it out!
- stouset 2y ago
  I expected it to be a bigger migration than it was. But I was using it effectively as a complete git replacement the very first day. I still had a few things I didn’t know how to do optimally, but it was close enough to be productive. Within a week I’d closed basically all of the gaps. It’s been three or so months now and I’m never going back. It’s been so transformative I can barely remember all the innumerable frustrations and papercuts I used to put up with daily. Rebase conflicts. Juggling the stash. Ugh. I say this as someone who considered themselves extremely proficient with git. I mean, I wrote a compatible Ruby implementation of it over a decade and ago. If it gains momentum, jj has a better chance than anything I’ve seen at finally dethroning git.
donatj 2y ago
One of the bigger things I try to hammer in to a junior developers mind is to be conscious and thoughtful about their individual commits. To basically never just "git add ." whatever might just happen to be different in their work area, but to ALWAYS review the diff and make the commit a logical collection of changes. With the lack of staging area it really seems like this encourages the exact opposite. Seems like a good way to get secrets as well as just general junk and clutter committed to your repo history. If I am working on a big project, I will start to commit change sets as parts of the code solidify without committing other less solid changes. That seems pretty basic. I don't want half finished changes forever committed to history.
- aduwah 2y ago
  Same here, I am doing a mess between commits, copying and comparing random files, hardcoding secrets for a quick test... To think that it ends up upstream is a thing of nightmares. I know, gitignore could help, but it eliminates the convenience of being flexible/quick&messy.
- martinvonz 2y ago
  This seems like a common misconception. The mention of the staging area in the README points to https://martinvonz.github.io/jj/latest/git-comparison/#the-index https://martinvonz.github.io/jj/latest/git-comparison/#the-i.... I'm guessing you didn't click that link. I suppose we need to inline part of the text where we link to it to reduce the number of confused readers. At this point, I wonder if maybe we should not even mention the staging area. It seems to confuse a lot of people, so maybe it hurts more than it helps to mention it.
  - deleted 2y ago
    [deleted]
  - martinvonz 2y ago
    Oh, I should also say that we have https://github.com/martinvonz/jj/issues/323 https://github.com/martinvonz/jj/issues/323 for your concern about automatically tracking files.
v3ss0n 2y ago
This getting spammed but developers .. they are afraid to change from git . Mercurial was much better than git in workflow and architecture wise and nobody care enough due to GitHub popularity. This will go the same , as well as sapling.
- stouset 2y ago
  As a counterpoint, jj has extremely good git interoperability. I and another teammate have switched over for several months and nobody on our team needs to know or care.
  - krick 2y ago
    Props to you, but this doesn't change my mind. VCS is intrinsically meant as a collaboration tool. If something goes wrong "jj did it" won't be a good excuse. If one needs to communicate his workflow to another, he better doesn't start with "well, you just install jj and...", he needs to explain, how to do that in git. If there is a junior dev on the team and I need to teach him common practices, I need to do that in the same personal-preference-agnostic manner, so I shouldn't teach him jj instead of git, even if I use it personally. Long story short, you need to be fluent in both, and even though I know git pretty well, I wouldn't even say I'm fluent in git: most of the time my fingers type stuff I don't conciously remember anymore, often relying on aliases and Ctrl+R. This is additional complexity, and it feels to me like I need it to be something HUGE to actually justify that.
    - stouset 2y ago
      Honestly this is a ridiculous take. Git is the native backend for jj. It is extremely reliable. There is no reason for "things to go wrong" uniquely to jj, particularly if you take basic precautions like forbidding force-pushes to master/main. For that matter plenty of people make mistakes with git itself, and having used both (and being a power user of git) I can confidently claim that there is significantly less surface area for mistakes with jj than there is with git. I have never, in 25 years of software development, needed to "communicate my workflow" with another engineer. It's understood that if I use a different tool than the rest of my team, I'm on the hook for knowing any differences in the workflow. But it's not even like this is unique to jj; my team uses a variety of editors/IDEs, operating systems, and shells. I use macOS, fish, VS Code, and jj. Others use nix, zsh, vim, and git. Somehow we all manage. The worst part is that your argument is trivially rewritten to discourage trying anything new. This is frankly a terrible mindset to have. If you don't want to learn a new tool, by all means don't. But not learning anything that might be different than what other people on your curent team use is a great way to completely stagnate your growth. That said, the argument I was responding to was that this can never take hold because of git's dominance. My point was that use of jj can grow organically since one person converting doesn't actually require the entire team to do so. Whether or not you're particularly hesitant to adopt new things is irrelevant; individuals can switch whenever they feel appropriate and it doesn't impact others.
hakube 2y ago
why does Git need to be replaced?
- krick 2y ago
  This. It's not like we are looking for something slightly better than git in some opinionated way. There's plenty better than git. Mercurial is better than git and as old as git. Git won. Everybody uses git. Everyone who knows, how to use git, is mostly comfortable using git. At this stage we either need something ground-breaking (and I don't quite imagine what this cold be in the context of VCS - even truly semantic conflict resolution barely cuts it, while simultaneously being pure unattainable magic), or I don't think this is gonna float. I don't need it. Who needs it? It's a relatively easy thing to adopt something you don't need, when you are the only person involved. But VCS is pretty much in the same category as instant messaging and social network platforms are. In a sense, maybe it is a social network platform. I don't see it happening and I highly doubt I would want it to happed, even if I knew this jj stuff better.
  - ezst 2y ago
    Git won because GitHub turned the whole contribution model into a resume-making social media game. The first generation on GitHub pressured the second one into using it at a time when the DVCS scene was still nascent (and git's many flaws, more excusable), and the second one, now turned into a critical mass, made it acceptable for the next to just cargo cult a few commands instead of learning their VCS, because that was the bare minimum to _partake in the game_, and an acceptable trade-off to deal with a now objectively user-hostile and inferior tool. The nice (and quite unique) thing about jj is that it takes all the good cues from systems which kept improving (and in particular, from mercurial), and slaps them onto git without requiring a storage model change, practically offering the social "perks" of GitHub (by being fully compatible with it), with no-compromise. And to be honest, at this point, there isn't much reason for a new comer to learn git rather than jj, and that's a wonderful news in my book.
    - krick 2y ago
      > isn't much reason for a new comer to learn git rather than jj The reason would be that jj uses git as a backend, and all your coworkers use git, and the whole world uses git, so using jj while not knowing git is like being "html-programmer" that doesn't know what RAM is. Surely one can live like that, but I wouldn't want to work with him. On other hand, what is the reason to learn jj rather than git? What actual problem it solves?
pictur 2y ago
Git is already as simple as possible with its own commands. I feel like we are making simple things more complicated with tools like this. If I start using this tool instead of git, I will probably start doing something hacky at some point. I don't want that. I don't want a history that keeps changing and getting weird with the use of rebase/squash. I don't think conflicts are a problem as long as a single history is kept up to date properly with git. The smoother the history, the easier it is to merge.
- Kuraj 2y ago
  > I don't think conflicts are a problem as long as a single history is kept up to date properly with git. That is easy when you work alone. It becomes more difficult as your team grows in size.
- lawn 2y ago
  Weird take as Git is making things much more complex than they need to be, which is proven by Mercurial and Jujutsu that are much more intuitive while being as powerful.
alberth 2y ago
Slightly OT: does anyone know why OpenBSD decided to build their own version of git, as opposed to using jujutsu (or another alternative)? https://www.gameoftrees.org/ https://www.gameoftrees.org/
- martinvonz 2y ago
  Jujutsu was started in late 2019. Got seems to have been started in late 2017. I have no idea why they didn't contribute to gitless instead of starting a new project.
MaximilianEmel 2y ago
How does this compare to Pijul[1]? [1] https://pijul.org/ https://pijul.org/
- MaximilianEmel 2y ago
  https://github.com/martinvonz/jj/commit/0525dc9d860a5fff6a97d134acc2c325aa36df30 https://github.com/martinvonz/jj/commit/0525dc9d860a5fff6a97...
masfoobar 2y ago
I have come from various version controls in my life. I remember CVS during my early Linux days. At work it was SourceSafe and around the 2010 era, worked for companies using TFS or SVN, etc. Each one of these had there issues. Some had a better relationship with SVN than others. I did not mind it. However, I HATED SourceSafe! Glad to never touch that again! When distributed version controls started to become a thing, I played with git, mercurial and bazaar before they were common. I liked them all better than SVN. Eventually I worked for a company using Mercurial but it wasn't long before git was the breadwinner and replaced practically everything else. Personally, the only reason I ended up on git is because is solved the problem of doing local commits. Many times I was not on the internet or local network, but I can commit whenever I like and push when available to do so. This, for me, was a HUGE win! Now, I dont have a reason to switch to something else. Its not comparable like moving from SVN to git. Could there be some cool or simpler features? Maybe. Regardless I hardly have issues with git overall to cause me to look about. The only "issue" I have came across with git is its not great for large binary files, or for storing a collection of images, etc. For coding - its awesome. I guess the only way I will starting considering alternatives is if the git team decide to make terrible choices.

94 points by vincent_s 2y ago

keikobadthebad 2y ago

stgit...

childintime 2y ago
https://stacked-git.github.io/ https://stacked-git.github.io/

setheron 2y ago

Honestly nothing of substance here. Would be great to get a first hand account of jj in practice.

chaychoong 2y ago
I have a short blog post here that describes some of my basic workflows: https://blog.chay.dev/basic-jj-workflows https://blog.chay.dev/basic-jj-workflows

viraptor 2y ago

How do people work with jujutsu and hacks/secrets? Having no staging feels like a disaster magnet to me where things that should never be published have a chance to be saved and distributed by accident. I consistently have some temporary workarounds / scripts / credentials / logs hanging around my repos while I work on things. I think I'd have to change my approaches significantly to use this safely.

xlii 2y ago
In short commit is your stage. It’s expected that you look at the commits before you push, the same as you do with staging. If you’d just "commit -am" the results would be the same. And since a commit can branch you can have a multiple (conceptual) stages. Jujutsu respects gitignore but cannot be told to not track in-file changes. Annoying when your peers commit customization files into the repository.
hoseja 2y ago
Targeted to the always online generation that does this automatically, probably. Whips in the soul.
3523582908 2y ago
I am a fan of the dev branch strategy [1], where I have a specific commit that holds all my customizations that I rebase off of. This blog post has it set up such that git automatically ignore pushing the dev commit, but I haven't really gotten that far yet. I just rebase my branch off current main when I'm ready to push. [1]: https://reasonablypolymorphic.com/blog/jj-strategy/index.html#the-dev-branch https://reasonablypolymorphic.com/blog/jj-strategy/index.htm...
aseipp 2y ago
Things like logs are just generally ignored in gitignore so they can just be there or whatever. In practice this hasn't been a huge problem for me. Hacks/workarounds/etc are actually pretty easy to handle and there are a couple strategies. The one I use is to use a merge commit. Let's say you have a patch P that you want to keep private (it hardcodes some build settings you like to use or whatever) and a patch A you want to work on. The base these changes are based off is B which is the upstream branch "main". Then, you create a merge between A and P, creating commit M, and your working copy (called @ or "at") sits on top: --> P --> / \ B (main) M --> @ \ / --> A --> And now, both `P` and `A` exist in your repository at the same time. Now, you can just use the `jj squash` command to take changes from `@` and put them inside either A or P, as you do your work, thus moving them "through" the merge commit M. These kinds of techniques where you move changes between commits are very common in Jujutsu so this is pretty natural once you get used to it. Note that you can also have `M = @`, i.e. the merge commit is the working copy itself. I prefer to keep the commit M separate and work "on top" of it like in the above graph, because you may solve a conflict between P and A, and M would be the correct place to put it, and you would want to keep it separate from everything else. A neat feature of this trick is that you can create a branch for change `A` and if you are sitting on top of `M`, and you run `jj git push`, then only `A` will be pushed and `P` will be ignored and left alone. In fact `P` will never be pushed unless you explicitly ask for it by creating the branch pointing to it. Nor is the merge commit ever pushed anywhere; it only exists so that you can have both changes available locally. I do this all the time these days in various forms, and in practice, the day-to-day stuff isn't terribly different than it is when you just leave things out of the staging area inside your working copy.

bdcravens 2y ago

While this is just a blog article, which is fine, I think the intended audience isn't sold on being told to run a couple of commands and install a mystery binary. (especially for those not already familiar with the Rust ecosystem and package manager) The actual project website is here: https://martinvonz.github.io/jj/latest/ https://martinvonz.github.io/jj/latest/ The repo is https://github.com/martinvonz/jj https://github.com/martinvonz/jj Note: the project author is a Googler, and it appears to be under the umbrella of Google/Alphabet, as a CLA is required: https://martinvonz.github.io/jj/latest/contributing/ https://martinvonz.github.io/jj/latest/contributing/

wodenokoto 2y ago

I’m as interested in the next git as much as the next guy, but this gives me no idea how I should or could work with jujutsu. Anonymous branches? How do I get back to my work? Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history? I have no impression of how this makes anything easier.

yawaramin 2y ago
I think this is just the hallmark of a new technology. Nobody understood how (or why) to use git when it first appeared either until people showed up who could communicate its benefits and UX really well.
- ahartmetz 2y ago
  Git, though, has the somewhat unique problem that its UX does a particularly bad job of explaining itself. Git isn't difficult because of its mind-bending awesomeness, but because the UX sucks. I'm fine with it, thankyouverymuch, but it was rote learning and I watch beginners struggle.
steveklabnik 2y ago
> Anonymous branches? How do I get back to my work? I fully appreciate this question, as I was there too until I started working with anonymous branches. Here's some sample output from jj log: $ jj log --limit 5 @ pzoqtwuv steve@steveklabnik.com 2024-03-01 15:06:59.000 -06:00 9353442b │ added some cool new feature │ ◉ xrslwzvq steve@steveklabnik.com 2024-02-29 23:06:23.000 -06:00 a70d464c ├─╯ create hello and goodbye functions │ ◉ yykpmnuq steve@steveklabnik.com 2024-02-29 23:03:22.000 -06:00 210283e8 ├─╯ add better documentation ◉ ootnlvpt steve@steveklabnik.com 2024-02-28 23:26:44.000 -06:00 b5db7940 │ only print hello world ◉ nmptruqn steve@steveklabnik.com 2024-02-28 23:09:11.000 -06:00 90a2e97f │ refactor printing Here, we are working on change 'pzoqtwuv'. (@ means the working copy.) There are colors in the real CLI to make the differences more obvious, and to show you unique prefixes, so for example, you probably only need 'p' or 'pz' instead of 'pzoqtwuv' to uniquely identify the change. I'll use the full IDs since there's no syntax highlighting here. We have two anonymous branches here. They have the change IDs of 'xrslwzvq' and 'yykpmnuq'. The log output shows the summary line of their messages, so we can see "create hello and goodbye functions" on one branch, and "add better documentation" on the other. You don't need an additional branch name: the change ID is already there. If you want to add even more better documentation, 'jj new yykpmnuq' (or again, likely 'jj new yy' in practice) and you're off to the races. (jj new makes a new change off of the parent you specify.) That's all there is to it. We already have the commit messages and IDs, giving an additional identifier doesn't help that much. (And if you're in a larger repo with more outstanding branches, you can ask 'jj log' to show specific subsets of commits. It has a powerful DSL that lets you do so. For example, say you only want to see your commits, 'jj log -r 'mine()'' can do that for you.) > Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history? The simplest answer is "you put that stuff in your .gitignore and it never gets committed." That said, it is recognized that sometimes that is not possible or easy. See https://github.com/martinvonz/jj/issues/323 https://github.com/martinvonz/jj/issues/323 for the current discussion about how to maybe support alternatives here. See also https://news.ycombinator.com/item?id=40917149 https://news.ycombinator.com/item?id=40917149 > I have no impression of how this makes anything easier. My take on this is that jj has fewer but also more orthogonal concepts. Naming things is hard. I don't like to do it. Not needing to name branches is really nice, as I don't really lose anything by not naming them, and I no longer have to name them. With regards to some other stuff, the "auto commit of saved files" really means that jj turns two of git's concepts, commits and the index, into one concept: commits. How is that easier? Well, I don't need to learn two sets of tools for dealing with the index vs a commit. For example, git has two kinds of resets: hard and soft. This is because git needs to have two sets of behaviors to deal with both concepts here, as git reset is about changing the index but maybe or maybe not the working tree. All of these distinctions don't matter in jj, because it's all just commits, so you use regular old tools on commits for them.

lifeformed 2y ago

What I want with a new git is first class support for large binary files. It's essential in game dev, and the best solution seems to be git lfs, which has its own problems.

reverius42 2y ago
This is what we’re building https://xethub.com https://xethub.com for! It’s a git forge with better support for large files (using git-xet instead of git-lfs) and it’s designed to store source code and binary assets in the same repo. Disclaimer: I work at XetHub.
martinvonz 2y ago
I hope we'll be able to do better once we have an open-source storage backend that stores contents in a central database (like we do with Jujutsu at Google).
- dastbe 2y ago
  is there any active work on an oss storage backend? any blockers in the jujutsu codebase to starting one?
  - martinvonz 2y ago
    I don't think anyone has started working on it. We would want a design doc first. Note that the solution probably involve a local daemon process for caching reads and optimistically accepting writes and then sending them to the server in the background. That's what we do for latency at Google. But that's just an optimization and can come after the server is done. If you're interested in working on it, it would help if you joined our Discord server.

snthpy 2y ago

I saw a youtube talk on this a year or two ago and it looked promising. I've been waiting to see more people take it up and sing its praises. This is the first HN post I've noticed since then. Any experiences of anyone trying it out and switching over to it?

snthpy 2y ago
I think this was the talk: https://youtu.be/bx_LGilOuE4?si=K7k0hqUmeXl8ULLf https://youtu.be/bx_LGilOuE4?si=K7k0hqUmeXl8ULLf I would like to know more about the first class conflict handling. That could potentially be useful for an application I have in mind but I need to understand the algorithms better. How does it compare to CRDTs or other merge strategies?
- stouset 2y ago
  The easiest way to think about it is that merge conflicts aren't something that causes operations to be aborted like they are in git. If you have a merge conflict or a rebase, conflict markers are inserted and everything continues. You can quickly see any commits that have merge conflicts. If some operation introduced them, you can go edit that commit and fix them. When you do so, the fix propagates forward automagically to all descendant commits. The benefit here is that the operation you were trying to do fully completes and you're never ejected into an intermediate state where changes are dropped into your working copy and you're expected to fix it right here and now before anything else happens. You don't have to unwind everything because you screwed up an earlier conflict resolution since everything is stored in history; you just go back to the commit you want to fix, make a change, and then jump back to the later commit that still needed some work.
3523582908 2y ago
It's been my daily driver for the last 3 months, and it's really amazing. Highly recommend trying it out!
stouset 2y ago
I expected it to be a bigger migration than it was. But I was using it effectively as a complete git replacement the very first day. I still had a few things I didn’t know how to do optimally, but it was close enough to be productive. Within a week I’d closed basically all of the gaps. It’s been three or so months now and I’m never going back. It’s been so transformative I can barely remember all the innumerable frustrations and papercuts I used to put up with daily. Rebase conflicts. Juggling the stash. Ugh. I say this as someone who considered themselves extremely proficient with git. I mean, I wrote a compatible Ruby implementation of it over a decade and ago. If it gains momentum, jj has a better chance than anything I’ve seen at finally dethroning git.

donatj 2y ago

One of the bigger things I try to hammer in to a junior developers mind is to be conscious and thoughtful about their individual commits. To basically never just "git add ." whatever might just happen to be different in their work area, but to ALWAYS review the diff and make the commit a logical collection of changes. With the lack of staging area it really seems like this encourages the exact opposite. Seems like a good way to get secrets as well as just general junk and clutter committed to your repo history. If I am working on a big project, I will start to commit change sets as parts of the code solidify without committing other less solid changes. That seems pretty basic. I don't want half finished changes forever committed to history.

aduwah 2y ago
Same here, I am doing a mess between commits, copying and comparing random files, hardcoding secrets for a quick test... To think that it ends up upstream is a thing of nightmares. I know, gitignore could help, but it eliminates the convenience of being flexible/quick&messy.
martinvonz 2y ago
This seems like a common misconception. The mention of the staging area in the README points to https://martinvonz.github.io/jj/latest/git-comparison/#the-index https://martinvonz.github.io/jj/latest/git-comparison/#the-i.... I'm guessing you didn't click that link. I suppose we need to inline part of the text where we link to it to reduce the number of confused readers. At this point, I wonder if maybe we should not even mention the staging area. It seems to confuse a lot of people, so maybe it hurts more than it helps to mention it.
- deleted 2y ago
  [deleted]
- martinvonz 2y ago
  Oh, I should also say that we have https://github.com/martinvonz/jj/issues/323 https://github.com/martinvonz/jj/issues/323 for your concern about automatically tracking files.

v3ss0n 2y ago

This getting spammed but developers .. they are afraid to change from git . Mercurial was much better than git in workflow and architecture wise and nobody care enough due to GitHub popularity. This will go the same , as well as sapling.

stouset 2y ago
As a counterpoint, jj has extremely good git interoperability. I and another teammate have switched over for several months and nobody on our team needs to know or care.
- krick 2y ago
  Props to you, but this doesn't change my mind. VCS is intrinsically meant as a collaboration tool. If something goes wrong "jj did it" won't be a good excuse. If one needs to communicate his workflow to another, he better doesn't start with "well, you just install jj and...", he needs to explain, how to do that in git. If there is a junior dev on the team and I need to teach him common practices, I need to do that in the same personal-preference-agnostic manner, so I shouldn't teach him jj instead of git, even if I use it personally. Long story short, you need to be fluent in both, and even though I know git pretty well, I wouldn't even say I'm fluent in git: most of the time my fingers type stuff I don't conciously remember anymore, often relying on aliases and Ctrl+R. This is additional complexity, and it feels to me like I need it to be something HUGE to actually justify that.
  - stouset 2y ago
    Honestly this is a ridiculous take. Git is the native backend for jj. It is extremely reliable. There is no reason for "things to go wrong" uniquely to jj, particularly if you take basic precautions like forbidding force-pushes to master/main. For that matter plenty of people make mistakes with git itself, and having used both (and being a power user of git) I can confidently claim that there is significantly less surface area for mistakes with jj than there is with git. I have never, in 25 years of software development, needed to "communicate my workflow" with another engineer. It's understood that if I use a different tool than the rest of my team, I'm on the hook for knowing any differences in the workflow. But it's not even like this is unique to jj; my team uses a variety of editors/IDEs, operating systems, and shells. I use macOS, fish, VS Code, and jj. Others use nix, zsh, vim, and git. Somehow we all manage. The worst part is that your argument is trivially rewritten to discourage trying anything new. This is frankly a terrible mindset to have. If you don't want to learn a new tool, by all means don't. But not learning anything that might be different than what other people on your curent team use is a great way to completely stagnate your growth. That said, the argument I was responding to was that this can never take hold because of git's dominance. My point was that use of jj can grow organically since one person converting doesn't actually require the entire team to do so. Whether or not you're particularly hesitant to adopt new things is irrelevant; individuals can switch whenever they feel appropriate and it doesn't impact others.

hakube 2y ago

why does Git need to be replaced?

krick 2y ago
This. It's not like we are looking for something slightly better than git in some opinionated way. There's plenty better than git. Mercurial is better than git and as old as git. Git won. Everybody uses git. Everyone who knows, how to use git, is mostly comfortable using git. At this stage we either need something ground-breaking (and I don't quite imagine what this cold be in the context of VCS - even truly semantic conflict resolution barely cuts it, while simultaneously being pure unattainable magic), or I don't think this is gonna float. I don't need it. Who needs it? It's a relatively easy thing to adopt something you don't need, when you are the only person involved. But VCS is pretty much in the same category as instant messaging and social network platforms are. In a sense, maybe it is a social network platform. I don't see it happening and I highly doubt I would want it to happed, even if I knew this jj stuff better.
- ezst 2y ago
  Git won because GitHub turned the whole contribution model into a resume-making social media game. The first generation on GitHub pressured the second one into using it at a time when the DVCS scene was still nascent (and git's many flaws, more excusable), and the second one, now turned into a critical mass, made it acceptable for the next to just cargo cult a few commands instead of learning their VCS, because that was the bare minimum to _partake in the game_, and an acceptable trade-off to deal with a now objectively user-hostile and inferior tool. The nice (and quite unique) thing about jj is that it takes all the good cues from systems which kept improving (and in particular, from mercurial), and slaps them onto git without requiring a storage model change, practically offering the social "perks" of GitHub (by being fully compatible with it), with no-compromise. And to be honest, at this point, there isn't much reason for a new comer to learn git rather than jj, and that's a wonderful news in my book.
  - krick 2y ago
    > isn't much reason for a new comer to learn git rather than jj The reason would be that jj uses git as a backend, and all your coworkers use git, and the whole world uses git, so using jj while not knowing git is like being "html-programmer" that doesn't know what RAM is. Surely one can live like that, but I wouldn't want to work with him. On other hand, what is the reason to learn jj rather than git? What actual problem it solves?

pictur 2y ago

Git is already as simple as possible with its own commands. I feel like we are making simple things more complicated with tools like this. If I start using this tool instead of git, I will probably start doing something hacky at some point. I don't want that. I don't want a history that keeps changing and getting weird with the use of rebase/squash. I don't think conflicts are a problem as long as a single history is kept up to date properly with git. The smoother the history, the easier it is to merge.

Kuraj 2y ago
> I don't think conflicts are a problem as long as a single history is kept up to date properly with git. That is easy when you work alone. It becomes more difficult as your team grows in size.
lawn 2y ago
Weird take as Git is making things much more complex than they need to be, which is proven by Mercurial and Jujutsu that are much more intuitive while being as powerful.

alberth 2y ago

Slightly OT: does anyone know why OpenBSD decided to build their own version of git, as opposed to using jujutsu (or another alternative)? https://www.gameoftrees.org/ https://www.gameoftrees.org/

martinvonz 2y ago
Jujutsu was started in late 2019. Got seems to have been started in late 2017. I have no idea why they didn't contribute to gitless instead of starting a new project.

MaximilianEmel 2y ago

How does this compare to Pijul[1]? [1] https://pijul.org/ https://pijul.org/

MaximilianEmel 2y ago
https://github.com/martinvonz/jj/commit/0525dc9d860a5fff6a97d134acc2c325aa36df30 https://github.com/martinvonz/jj/commit/0525dc9d860a5fff6a97...

masfoobar 2y ago

I have come from various version controls in my life. I remember CVS during my early Linux days. At work it was SourceSafe and around the 2010 era, worked for companies using TFS or SVN, etc. Each one of these had there issues. Some had a better relationship with SVN than others. I did not mind it. However, I HATED SourceSafe! Glad to never touch that again! When distributed version controls started to become a thing, I played with git, mercurial and bazaar before they were common. I liked them all better than SVN. Eventually I worked for a company using Mercurial but it wasn't long before git was the breadwinner and replaced practically everything else. Personally, the only reason I ended up on git is because is solved the problem of doing local commits. Many times I was not on the internet or local network, but I can commit whenever I like and push when available to do so. This, for me, was a HUGE win! Now, I dont have a reason to switch to something else. Its not comparable like moving from SVN to git. Could there be some cool or simpler features? Maybe. Regardless I hardly have issues with git overall to cause me to look about. The only "issue" I have came across with git is its not great for large binary files, or for storing a collection of images, etc. For coding - its awesome. I guess the only way I will starting considering alternatives is if the git team decide to make terrible choices.