Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow.
I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration.
Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over.
[1] https://github.com/arxanas/git-branchless
[2] ht
arxanas
git-branchless
Rust2021–2025
arxanas / git-branchless
git-branchless
High-velocity, monorepo-scale workflow for Git
26Distinct people
65Mentions
0Explicit recommenders
4.1KGitHub stars
What to know before exploring
What it is
High-velocity, monorepo-scale workflow for Git
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- jj-vcs/jj · linked in 6 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year65 dated mentions
Observed mentions: 2021-03-29 17:08:51 UTC to 2025-12-20 07:55:29 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 23 | 2 | 21 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 20 | 2 | 18 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 1 | 6 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Branchless workflow for Git
(This suite of tools is 100% compatible with branches. For more discussion, see this thread.)
▼ Jump to installation ▼
▼ Jump to table of contents ▼
About
git-branchless is a suite of tools which enhances Git in several ways:
It makes Git easier to use, both for novices and for power users. Examples:
git undo: a general-purpose undo command. See the blog post git undo: We can do better.
The smartlog: a convenient visualization tool.
git restack: to repair broken commit graphs.
Speculative merges: to avoid being caught off-guard by merge conflicts.
It adds more flexibility for power users. Examples:
Patch-stack workflows: strong support for "patch-stack" workflows as used by the Linux and Git projects, as well as at many large tech companies. (This is how Git was "meant" to be used.)
Prototyping and experimenting workflows: strong support for prototyping and experimental work via "divergent" development.
git sync: to rebase all local commit stacks and branches without having to check them out first.
git move: The ability to move subtrees rather than "sticks" while cleaning up old branches, not touching the working copy, etc.
Anonymous branching: reduces the overhead of branching for experimental work.
In-memory operations: to modify the commit graph without having to check out the commits in question.
git next/prev: to quickly jump between commits and branches in a commit stack.
git sw -i/--interactive: to interactively select a commit to switch to.
It provides faster operations for large repositories and monorepos, particularly at large tech companies. Examples:
See the blog post Lightning-fast rebases with git-move.
Performance tested: benchmarked on torvalds/linux (1M+ commits) and mozilla/gecko-dev (700k+ commits).
Operates in-memory: avoids touching the working copy by default (which can slow down git status or invalidate build artifacts).
Sparse indexes: uses a custom implementation of sparse indexes for fast commit and merge operations.
Segmented changelog DAG: for efficient queries on the commit graph, such as merge-base calculation in O(log n) instead of O(n).
Ahead-of-time compiled: written in an ahead-of-time compiled language with good runtime performance (Rust).
Multithreading: distributes work across multiple CPU cores where appropriate.
To my knowledge, git-branchless provides the fastest implementation of rebase among Git tools and UIs, for the above reasons.
See also the User guide and Design goals.
Table of contents
About
Demos
Repair
Visualize
Manipulate
Installation
Status
Related tools
Contributing
Demos
Repair
Undo almost anything:
Commits.
Amended commits.
Merges and rebases (e.g. if you resolved a conflict wrongly).
Checkouts.
Branch creations, updates, and deletions.
Why not git reflog?
git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository.
git reflog also fundamentally can't be used to undo some rare operations, such as certain branch creations, updates, and deletions. See the architecture document for more details.
What doesn't git undo handle?
git undo relies on features in recent versions of Git to work properly. See the compatibility chart.
Currently, git undo can't undo the following. You can find the design document to handle some of these cases in issue #10.
"Uncommitting" a commit by undoing the commit and restoring its changes to the working copy.
In stock Git, this can be accomplished with git reset HEAD^.
This scenario would be better implemented with a custom git uncommit command instead. See issue #3.
Undoing the staging or unstaging of files. This is tracked by issue #10 above.
Undoing back into the middle of a conflict, such that git status shows a message like path/to/file (both modified), so that you can resolve that specific conflict differently. This is tracked by issue #10 above.
Fundamentally, git undo is not intended to handle changes to untracked files.
Comparison to other Git undo tools
gitjk: Requires a shell alias. Only undoes most recent command. Only handles some Git operations (e.g. doesn't handle rebases).
git-extras/git-undo: Only undoes commits at current HEAD.
git-annex undo: Only undoes the most recent change to a given file or directory.
thefuck: Only undoes historical shell commands. Only handles some Git operations (e.g. doesn't handle rebases).
Visualize
Visualize your commit history with the smartlog (git sl):
Why not git log --graph?
git log --graph only shows commits which have branches attached with them. If you prefer to work without branches, then git log --graph won't work for you.
To support users who rewrite their commit graph extensively, git sl also points out commits which have been abandoned and need to be repaired (descendants of commits marked with rewritten as abcd1234). They can be automatically fixed up with git restack, or manually handled.
Manipulate
Edit your commit graph without fear:
Why not git rebase --interactive?
Interactive rebasing with git rebase --interactive is fully supported, but it has a couple of shortcomings:
git rebase --interactive can only repair linear series of commits, not trees. If you modify a commit with multiple children, then you have to be sure to rebase all of the other children commits appropriately.
You have to commit to a plan of action before starting the rebase. For some use-cases, it can be easier to operate on individual commits at a time, rather than an entire series of commits all at once.
When you use git rebase --interactive with git-branchless, you will be prompted to repair your commit graph if you abandon any commits.
Inst
Read the full README on GitHubWhat Hacker News says
65 sourcesIn Graphite is joining Cursor
git-branchless implements revsets for git https://github.com/arxanas/git-branchless/wiki/Reference:-Re...
In Jujutsu for everyoneI tried it for a bit and went back to git-branchless (https://github.com/arxanas/git-branchless).
git-branchless is just a better set of tools for working on a git repo so local tools like the JetBrains git integration will work just fine.
It operates on a similar philosophy to Jujutsu (make it easy to manipulate the commit tree) and the authors did exchange ideas with each other.
In Jujutsu for busy devsOne trick for running tests in rebase-heavy workflows is to use the tree hash of the commit as the cache key, rather than attach metadata the commit itself.
- That way, tests will be skipped when the contents of the commit are the same, while remaining insensitive to things like changes to the commit message or squashes.
- But they'll re-run in situations like reordering commits (for just the reordered range, and then the cache will work again for any unchanged commits after that). I think that's important because notes will follow the commits around as they're rewritten, even if the logical contents are now different due to reordering? Amending a commit or squashing two non-adjacent commits may also have unexpected behavior if it merges the notes from both sides and fails to invalidate the cache?
- This is how my `git test` command works
Read the rest
https://github.com/arxanas/git-branchless/wiki/Command:-git-...
---
I've also seen use-cases might prefer to use/add other things to the cache key:
- The commit message: my most recent workflow involves embedding certain test commands in the message, so I actually do want to re-run the tests when the test commands change.
- The patch ID: if you specifically don't want to re-run tests when you rebase/merge with the main branch, or otherwise reorder commits.
Unfortunately, I don't have a good solution for those at present.
It's certainly true that jj's features won't appeal to everyone. I think a lot of its features are quality-of-life features (consistent commands and concepts, general undo), and a lot of its features don't help a certain class of users (flexible commit rewriting/rebasing), so it's not surprising that some seasoned Git users won't find it that helpful.
I think it's unfair to call it a "thin UI layer". My own project git-branchless https://github.com/arxanas/git-branchless might more legitimately be called a "thin UI layer", since it really is a wrapper around Git.
jj involves features like first-class conflicts, which are actually fairly hard to backport to Git in a useful way. But the presence of first-class conflicts also converts certain workflows from "untenable" to "usable".
Another comment also points out that it was originally a sid
Read the rest
e-project, rather than a top-down Google mandate.
jj is pretty much just safer than Git in terms of the core architecture.
There's several things Git can't undo, such as if you delete a ref (in particular, for commits not observed by `HEAD`), or if you want to determine a global ordering between events from different reflogs: https://github.com/arxanas/git-branchless/wiki/Architecture#...
In contrast, jj snapshots the entire repo after each operation (including the assignment of refs to commits), so the above issues are naturally handled as part of the design. You can check the historical repo states with the operation log: https://jj-vcs.github.io/jj/latest/operation-log/ (That being said, there may be bugs in jj itself.)
In jj: a Git-compatible VCS that is both simple and powerfulGit-branchless: High-velocity, monorepo-scale workflow for Git
3 points · Open discussionYou can run the tests on each commit in parallel if you're okay with wasting CPU time to save wall-clock time. git-branchless can speculatively run linear or binary search in parallel up to a user-specified number of jobs [1], and I'd like it add it to jj someday, as it's one of the features I miss most.
(To run the tests in parallel, git-branchless provisions its own worktrees. For binary search, it speculatively executes the search for the potential success and failure cases; when the number of jobs is a power of 2, this partitions the search space evenly.)
[1]: https://github.com/arxanas/git-branchless/wiki/Command:-git-...
In Ask HN: Git Alternatives – Sapling vs. JjOne of the main reasons to use git-branchless over jj or Sapling is if you need support for a workflow that's not supported in jj/Sapling yet, such as Git LFS. I (git-branchless author) would like to see both systems get to feature parity one day to unblock users who would like to migrate but can't.
These days, there are relatively few things that git-branchless can do that jj/Sapling can't, one example being its (somewhat opinionated) `git test` command: https://github.com/arxanas/git-branchless/wiki/Command:-git-...
In Ask HN: Git Alternatives – Sapling vs. JjFor more info, here are some git-branchless write-ups on the topics:
- https://blog.waleedkhan.name/git-undo/ — has a link to this article explaining some things that can't be undone in the Git model via reflog: https://github.com/arxanas/git-branchless/wiki/Architecture#...
- https://blog.waleedkhan.name/in-memory-rebases/ — It's non-trivial to support workflows like "rebase just commit X out of its branch and insert it before commit Y in that branch" in a single command. jj implements the same workflows as well.
- https://blog.waleedkhan.name/bringing-revsets-to-git/
In Ask HN: Git Alternatives – Sapling vs. JjIt's a fair question, but the answer is simple: because there are significant design choices in the UX and algorithms which are user visible, and percolate throughout the entire system design, which can't just be wrapped or alias'd away.
There is git-branchless, which is kind of like this[1][2] and is something like a half-way point between Git and Jujutsu/Sapling. However, it needs to be stated that git branchless does NOT just "wrap" existing things or alias them. It has significant engineering to add features, using a lot of code, because you can't "just" add things like revsets or 'undo' using wrappers or aliases, at least not in an efficient way.
Some examples from Jujutsu are that:
A) jj rebase is lightning fast compared to git rebase, because it works in memory. Git rebase touches disk for all operations, so it becomes slower the l
Read the rest
arger the repo, the more history, the bigger the files etc you have. You may spend significant IOPS moving large-ish files around, flushing the index to disk, and so forth; and you also cannot do things like rebase inside a bare repository (imagine you want a handy "Rebase branch on main" button in your GUI -- you need to have the whole working copy to do that!) jj rebase works entirely in memory so it never touches the disk for any files in the commits themselves. This is called "git move" in git-branchless, but requires significant code. Git itself is trying to solve this with a new "git replay" command, but it is extremely new and has some current limitations compared to, say, Jujutsu, IIRC. (But the fact they have to add a whole new command with significant code is a good example of how the algorithmic differences matter and can't be papered over.)
B) Revsets are a non-trivial addition to make the commit graph "queryable", but they add open ended features in a way that can't easily be recreated without them, because they are composable. For example, "list all commits authored by me that are not merged into main that can be rebased on main" is written as `all:mutable() & mine()`, but to recreate this level of flexibility you would need a dozen one-off features added to something like 'git log' -- but these revsets can work with many more commands than log! You can use the above revset to automatically rebase all your open branches at once for example, which is not possible in Git without shell scripting (what about Windows users?) and duct-taping stuff. But then where's the reuse?
C) Jujutsu has a notion of first-class conflicts, which can only be vaguely approximated with something like `git rerere` and `git rebase --update-refs`, but this isn't quite the same because for example you need to know details like purging the rerere cache if you get a conflict resolution wrong and want to undo it and start over, not to mention you can still easily screw things up mid-way with `git rebase` in a form that requires you to start over. These "catches" do not apply to Jujutsu and I have no idea where you would even begin if you wanted to add a feature like this.
So, the details matter a lot in practice for users, and delivering them a good experience is something that I think is way more difficult than just a bunch of opinionated commands. To be clear, if you like opinionated aliases and wrappers, that's OK! But there's a lot more underneath the surface if you scratch at it a bit.
[1] https://github.com/arxanas/git-branchless
[2] The main developer of git-branchless also is a Jujutsu contributor, so these ideas and the implementations aren't totally a coincidence!
From the git-branchless wiki:
https://github.com/arxanas/git-branchless/wiki/Concepts#anon...
> Normally, only commits which are reachable by a branch are visible in stock Git.
But this is not true: a "soft" tag suffices to keep a pseudo-branch visible to, say git-log --graph. In my own workflow, I've let these replace temporary branches proper.
In Creating a Git Commit: The Hard WayWhen I was doing more hardcore dev instead of SRE'ing I settled on git branchless[1], was well worth the experimenting you have to do to get it into your mental model.
now that I hardly ever have 2 layer deep stacks I just settle on my go-to git client which is magit. It just takes a couple of keystrokes to do a couple of stacked rebases.
I do wish that the stacked commits approach was universally used instead of the approach that github enforced on us. It just makes everything a bit less arcane. The whole 'branch-dance' gets really old real fast.
[1]: https://github.com/arxanas/git-branchless
In Working with stacked branches in Git is easier with –update-refs (2022)Yes, but due to its simplicity + extensibility + widespread adoption, I wouldn’t be surprised if we’re still using Git 100+ years from now.
The current trend (most popular and IMO likely to succeed) is to make tools (“layers”) which work on top of Git, like more intuitive UI/patterns (https://github.com/jesseduffield/lazygit, https://github.com/arxanas/git-branchless) and smart merge resolvers (https://github.com/Symbolk/IntelliMerge, https://docs.plasticscm.com/semanticmerge/how-to-configure/s...). Git it so flexible, even things that it handles terribly by default, it handles
fine with layers: e.g., large binary files via git-lfs (https://git-lfs.com) and merge conflicts in non-textual files by custom merge resolvers like Unity’s (https://flashg.github.io/GitMerge-for-Unity/).
Perhaps in the future, almost everyone will keep using Git a
Read the rest
t the core, but have so many layers to make it more intuitive and provide better merges, that what they’re using barely resembles Git at all. This flexibility and the fact that nearly everything is designed for Git and integrates with Git, are why I doubt it’s ever going away.
Some alternatives for thought:
- pijul (https://pijul.org), a completely different VCS which allegedly has better merges/rebases. In beta, but I rarely hear about it nowadays and have heard more bad than good. I don’t think we can implement this alternate rebases in Git, but maybe we don’t need to; even after reading the website, I don’t understand why pijul’s merges are better, and in particular I can’t think of a concrete example nor does pijul provide one.
- Unison (https://www.unison-lang.org). This isn’t a VCS, but a language with a radical approach to code representation: instead of code being text stored in files, code is ASTs referenced by hash and stored in essentially a database. Among other advantages, the main one is that you can rename symbols and they will automatically propagate to dependencies, because the symbols are referenced by their hash instead of their name. I believe this automatic renaming will be common in the future, whether it’s implemented by a layer on top of Git or alternate code representation like Unison (to be clear, Unison’s codebases are designed to work with Git, and the Unison project itself is stored in Git repos).
- SVN, the other widespread VCS. Google or ask ChatGPT “Git vs SVN” and you’ll get answers like this (https://www.linode.com/docs/guides/svn-vs-git/, https://stackoverflow.com/a/875). Basically, SVN is easier to understand and handles large files better, Git is decentralized and more popular. But what about the differences which can’t be resolved by layers, like lazygit for intuition and git-lfs for large files? It seems to me like even companies with centralized private repositories use Git, meaning Git will probably win in the long term, but I don’t work at those companies so I don’t really know.
- Mercurial and Fossil, the other widespread VCSs. It seems these are more similar to Git and the main differences are in the low-level implementation (https://stackoverflow.com/a/892688, https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#....). It actually seems like most people prefer Mercurial and Fossil over Git and would use them if they had the same popularity, or at least if they had Git’s popularity and Git had Mercury or Fossil’s. But again, these VCSs are so similar that with layers, you can probably create a Git experience which has their advantages and almost copies their UI.
Some of the recent tool started to come out to fix Git unfriendly UX.
Meta's Sapling (1) is definitely one of them. But there is also `jj` (2) and `git-branchless` (3). These tools target a smaller set of workflow where there is 1 main branch inside a big repo and everything else are short-lived branch/topic that could be treated as ephemeral stack of patches, constantly being uproot / rebase on top of the main branch to derive final result.
If that's the workflow you use daily, then you should give these tools a try.
(1): https://github.com/facebook/sapling
(2): https://github.com/martinvonz/jj/
(3): https://github.com/arxanas/git-branchless
In Meta developer tools: Working at scaleShowing the 15 most recent of 65 sources. Enable JavaScript to search and browse every indexed mention.