HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
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
REPOSITORY AT A GLANCE

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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 AM 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.

05101520252021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 23 mentions; 2 submissions, 21 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 20 mentions; 2 submissions, 18 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC23221
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC20218
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC918
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC606
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC716

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 GitHub

What Hacker News says

7 sources
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
Read the rest
In Graphite is joining Cursor
I 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 devs
One 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.
In Git Notes: Git's coolest, most unloved­ feature (2022)
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.
In JJ Cheat Sheet
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 powerful

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.