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.
There isn't an "explicit" staging area in the sense it's a separate semantic concept that is distinct from a "commit"; rather, the provided machinery for working with commits can be used to do all the things you do with the staging area. The staging area is subsumed as a concept by another concept. By the same token, it also subsumes the stash too. In other words, you can do all the same workflows you do now, but there are fewer "nouns" to juggle. In Git there's the working copy, staging area, and commits. In Jujutsu, there are only commits, and commits are used in more generalized ways with more generalized operations.
To put it another way: the staging area is great because it's really easy to manipulate and "chop it up" as you like. If you make commits themselves really easy to manipulate, just as easy as the staging area, then you can just get rid of the staging area and use commits instead i.e. split a commit in two, or squash two commits together, or parallelize them or reorder them, etc. This actually means that many workflows in Jujutsu are more open ended and flexible than the Git equivalents, while simultaneously having less nouns (which means that, for example, there are fewer UX irregularities because there's less surface area.)
The README that Martin mentions first says there's "no staging area", but then a few paragraphs later mentions that the working copy concept subsumes it and so it provides a superset of functionality. That should probably be rewritten.
I use Jiujitsu, and my personal experience is that the basic "write code, git add what specifically I want to history" flow is the same. The working commit is the effective staging area and it doesn't get forever committed to public history. Without going too much in detail, the working commit can't be pushed to your remote, similar to how the staging area can't be pushed.
Your currently active commit is the staging area, only now that it's a "real" commit instead of some bastard half-commit all of your regular tools work with it directly. Same goes with the stash, it's rendered completely irrelevant.
When you're ready to "commit", you give a description to your current set of changes (`jj describe -m`) and then split out any of the pieces you don't want into the next commit (`jj split`). You get to pick the parts you want pulled out, and those get pulled out onto a new, fresh commit.
There's a notion of "empty commits" (commits without messages) in JJ. These are basically the "staging area" of git, and if you try to `jj git push` it JJ will reject. So these commits cannot make it to the remote branch.
To be honest, JJ makes it way easier for me to craft clean commits. The design philosophy of JJ is commit-oriented, not branch-oriented. Since it's a frontend to git, everything it does is fundamentally git. But it allows commit-oriented workflows to flow so much easier than git does.
> To basically never just "git add ." whatever might just happen to be different in their work area
> I will start to commit change sets as parts of the code solidify without committing other less solid changes
I feel like you are pushing your idiosyncratic way of working on others. It's great that you have a way that works for you, but it seems rather odd to me that you would ever be working on more than one thing in the same staging area.
I always git add -a . because I'm working on one specific thing, and my tests just passed.
jj makes this extremely easy by the way. One sample way to do it:
1. jj new (create new change)
2. <make typo fix>
3. jj edit @- (please go back to editing the previous change: @ is the working directory, - means previous. kinda like HEAD^ in git)
You're done in a few seconds, and can get back to your regular work, while that change is split out into its own thing. If you're not as comfortable with the anonymous stuff, you could also `jj new -m 'typo fix'` to set a message then, but for small stuff like this, I don't personally bother until I am done with what I'm actually working on and am ready to submit that too.
If you’re treating @ like the git index (sometimes called the “squash workflow”) then you’d just do the same thing you do in git: squash each part of @ into the proper commit.
Of course, you could also just make it in the current change, and split it out later, but that's easier to forget imho.
Since I started with lazygit, I do it a lot less. The tool makes it extremely easy to select what changed lines belong to which commit. And easy things are done more commonly than hard things.
> I don't want half finished changes forever committed to history.
This is exactly why I hew to squash+rebase. As I like to put it "I don't care about every little sneeze a developer had." Git has spoiled me with this, where I have the power to commit to my private repo anything I damn well please, but in the end I can clean things up and keep the central repo clean and bisectable[0].
Any VCS that doesn't offer these (squash, rebase, bisect) is a complete non-starter for me.
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-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.
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.
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)
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.
This is what we’re building 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.
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).
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.
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.
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.
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.
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.
I wouldn't say afraid but don't see the reason. Vast Majority of Developers are working where repo = single application and their git workflow is Scaled Trunk Based: https://trunkbaseddevelopment.com/#scaled-trunk-based-develo... main, branch, work, merge, repeat and they almost always fix forward.
Also, Rebasing is cause for Dev Riots because of nightmare merge conflicts that can result.
Since the author is from Google, my guess is they are seeing issues that hit the level of "WE MUST FIX THIS" that only arise at Google Monorepo size.
Jujutsu supports using Git repositories as the underlying repo format, in fact you can even run most of your `git` commands in the exact same repository -- and it is otherwise unnoticeable to anyone beyond yourself, barring customized setups. And we're committed to supporting and improving our Git integration, as long as Git is useful, and our users need it. We're not going anywhere :)
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.
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.
Good for you that you have only one team mate. I have 15 of them at varying skill levels. As organization grew bigger Murphy laws kicks in.
We love mercurial but we have to change because the whole world had move to git and developer need to learn two different collaboration tools and then even mercurial hg-git ext works well we have to move away from it.
Your teammates don't have to care. That is the point. It's only a thing on your local computer. The team sees all the normal stuff they'd see if you used git.
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.
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.
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.
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 for the current discussion about how to maybe support alternatives here.
> 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.
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.
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.
> 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?
"the whole world uses git" is a weak appeal to the masses (Argumentum ad populum), i.e. the popularity of git is no measure for its qualities, and we should collectively strive for better (just looking around should make it painfully obvious that there are many good things that git is lacking).
We previously saw that git is in fact two very distinct things: a repo format and a user interface; and we saw that git is too critical a mass to be dislodged as a repository format.
The next best thing we can do is then to address its disastrous UX, and this is precisely what jj is about. And it tackles that without even incurring "contagious" changes in established organizations: neither you or I have to know/care whether others are using git-cli/vscode gui/jj/whatever.
This is progress, because teaching git to this day is in equal parts teaching "DVCS theory", git "the useful parts", git "the very many pointy bits not to get too close to", and git "I messed it up, please help me rescue my files".
At least jj offers to simplify the learning while improving on the experience greatly, by offering a very cohesive, straightforward, discoverable safe and mostly trouble-free implementation whose tenets that can be intuited from the theory.
Jujutsu has Git as a supported backend, so it does not need network effects to succeed. I was using it full time at Oxide for many months before anyone else was aware of it.
More generally: I am more knowledgeable about version control than 99% of people (having worked on it full time for many years). The Git UI is well beyond papercut bad. Many advanced users use the rebase-interactive workflow, which is broken in numerous ways.
See my testimonial (top one on the page) for an example where Jujutsu's rethink of VCS basics leads to an incredibly coherent interface. Jujutsu is built by world-class developers who have spent many years working on other systems and drawing lessons from them, and it shows! https://martinvonz.github.io/jj/latest/testimonials/
If I were introducing version control to someone new, I would not be proud of introducing Git and would constantly apologize for it. I'd be proud of introducing Jujutsu.
Why do we invent new programming languages? We can achieve everything with just C or assembly.
As an example of something that's much easier in Jujutsu and very difficult with Git is to work on all branches at the same time. With Jujutsu you can rebase all branches simultaneously too.
See my testimonial in the other reply to yours. Jujutsu is both more approachable to newcomers and does a fantastic job catering to some of the most advanced workflows. It is truly special (this is not something I'd say for almost any other software project).
I've read it, but it doesn't quite answer my question. What I'm hearing is basically "well, it's nicer". Sure, I can believe that even not delving into the subject, because pretty much everything is nicer than git. A bunch of aliases and 3rd party diff are nicer than default git too, I don't think this is what we are talking about. But what problem it solves?
You are saying that rebase-interactive workflow is broken. I do rebase-interactive a lot. Well, maybe it is broken, maybe I would get annoyed about it beyond belief if I spent as much time messing with its internals as you (supposedly) did. But I don't think I often have problems with it as a user. I guess conflict-handling could have been much smarter, but if I keep "temporary" commits very small and atomic it somehow manages to do the job better than I sometimes expect, and in the end I don't think I have any problems with it whatsoever. So, once again, what is the problem jj solves? Can you give some practical, not overly-contrived example when using jj over git is not "nice", but significantly useful, when it saves me somehow?
Let's say you have a stack of three commits, A <- B <- C. Let's say you do a git rebase -i with edit commands on A and B. You make some changes to A, then you go and edit B.
But then you realize that some changes you wanted to make to B, you want to make to A instead -- you want to go back to A.
git rebase -i doesn't let you go back to A. (In other words, the modal nature of git rebase -i means that you can't do a rebase -i inside of a rebase -i.) Instead, you must complete the rebase -i and go to C, and start a new rebase -i.
Now that doesn't sound like a problem, but let's say C is not just 1 commit, it's 10 or even 20. And maybe there are branches with experimental work that you're grabbing bits and pieces of.
And those commits have significant merge conflicts that you must resolve immediately before you can go back to A.
In contrast, Jujutsu isn't modal. You can freely move up and down a stack, and merge conflict resolution can be deferred until later.
(This isn't a contrived example. I literally just finished up a few weeks' work on a stack of 14 rather substantial commits. At its peak, 12 commits were outstanding, totaling around 15k lines of code. Jujutsu handled this extremely well.)
edit: apologies, monospace formatting isn't working well on HN. But I hope you get the gist.
Thanks, this is something to consider at least. However, it doesn't convince me still. While I understand your problem, this problem doesn't really occur in my workflow, so a tool that encourages this workflow doesn't seem appealing and I cannot answer myself yet, why would I need to introduce this problem.
This is because I pretty much never use "edit". Well, not "never", but I avoid it, and it is perfectly avoidable in the vast majority of cases. Also, I don't like to deal with conflicts, as they are error prone, so I try to avoid them as well. Every time I want to change something in an old commit (on the same branch) I'll just add a new commit with barely comprehensible commit message, and I commit every little change. Also, if there is an atomic change in 2 files (function renamed), I usually commit them separately, including file name in the message. Then, after finishing some significant part of work, I'll rebase -i master, reorder commits and most of these "new" fixes will end up with "f" modifier after an olde commit, some I'll just drop. I'll do it in multiple iterations, to see which (reordering) operation results in a conflict, to keep conflict resolution operation as small and straight-forward as possible. So being modal is a good thing, as I'll run rebase a half-dozen times, before changes made up to the moment are all cleared up and I can move forward with committing new stuff. I never want to stay inside of one "rebase" operation for long, if I do, I'll probably --abort, and stop to reconsider what I'm doing here.
Even if "editing" past commit would be completely effortless, I just don't want to do that, because I don't want to think about how "later" changes might affect this place. When I do that, there is a whole new class of potential human mistakes one could make, that just doesn't exist when you always work on the "latest" version of the code. In worst case scenario, I might break some intermediate commit when carelessly reordering stuff, but the final code result must remain the same as before I did rebase. If this isn't the case, there is this uncomfortable scenario that I make some edit which is logically incompatible with a "later" conflict, which I won't notice if it doesn't cause a conflict: and it totally might not cause a conflict. I don't want to worry about that.
It is certainly possible that this particular improvement isn't hugely relevant to you. However this is well beyond "it's nicer" -- it has been a game-changer for me, and the core ideas Jujutsu is built out of result in many such improvements across all kinds of workflows. And I want to emphasize again that this is not contrived; it is how I actually did some work recently.
But also, tools shape our behaviors. Your current workflows are influenced by how Git works, and it's quite possible with Jujutsu you'll change your workflows. Maybe in a direction that you'll like more in the end.
One simple example is undo. You can simply run `jj undo` if you made a mistake (it obviously won't unpush commits to a remote and such). You can go back as many steps as you like.
For me, this framing is backwards: git cannot achieve what I can with jj. jj has everything I love about git, is more powerful, and is more orthogonal (read: simpler).
I have been using Git for 8 years and haven't had any bad experiences with CLI. And this one and other tools that are supposed to replace Git are better in what way? The only thing that's better in this is the conflict resolution but other than that, it doesn't offer that much.
I've used Git for over 16 years and have countless of papercuts with the CLI. Of course as you grow more experienced you eventually memorize the commands you end up using despite them not having much consistency (git checkout removes files, but it also changes or creates branches for instance).
This is a major pain for people learning Git for the first time and basically everyone have run into these issues, while a more user-friendly tool would've saved so much pain and suffering. There's a reason why most people cling to a Git GUI like their life depends on it.
Being easier to learn and reason about together with better conflict resolution and rebasing are substantial improvements I'd say.
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.
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.
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.
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?
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.
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?
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.
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.