Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?”
You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference).
I’ve wondered if there is a psychological thing here: someone who spent time memorizing all the git nonsense may have some pride in that (which is earned, certainly), that introduces some mental friction in walking away???
I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does.
jj is harder to adopt for people with a thorough mental model of git, because it's harder to accept jj commands at face value. I know it's modifying my git tree, so I feel compelled to grok exactly what it's doing, but that's distracting and time consuming.
People like me should probably trial jj exclusively for two weeks, to shed that antijjotic resistance and form a more clear-headed opinion.
> jj is harder to adopt for people with a thorough mental model of git
No, it really isn’t. I have used git since shortly after it was first released and I’ve written a git implementation.
I switched to jj in one day. And the amount of git arcana I have to keep in working memory is now basically nil. My VCS now works in almost a 1:1 mapping with how my brain wants to interact with my repo rather than having to go through a translation layer.
If you understand what git commands are doing, what jj does is essentially trivial to add to your mental model.
I also get the benefit of being able to use workflows that I always want to use in git but which are an enormous pain in practice. And I get access to wildly powerful new workflows I didn’t even consider because they would be outlandish in git.
What I will say is this: there is certainly an adjustment period, and I also totally hear you about how learning internals can be time consuming.
I think you can get a lot of the way there with at least the core concept with something like this, if you'll indulge me:
With git, you build up stuff on your filesystem. You then select which bits go into a diff in your index, and then when you're done, you stamp out a commit.
With jj, you instead start by creating a commit. In this case, it's empty. Then, every time you run a jj command, it does a snapshot, and this produces a new commit. However, because we want to have a stable identifier for a commit, we introduce a new one: the change id. This is basically an alias for the latest commit snapshot that was made. Your git history is just made up of each of these latest commits for each change.
... does that make any sense? Obviously there's more to all of the features than this, but that's sort of the core way that the histories map to each other.
It's not a trick or workaround. It's a very straightforward use of a command flag on one of the most used git commands. It's even conceptually very simple, you're just rebasing a subset of commits of a branch onto a different parent. Anyone who has ever rebased already has a working mental model of this operation. Framing this issue where knowing a single flag on a command every git user uses every day to perform an operation they already broadly understand as some arcane knowledge and 'nonsense' is ridiculous.
> introduces some mental friction in walking away???
I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zero. Switching to jj means learning another tool to achieve similar outcomes on your workflows.
If jj took many weeks of relearning, I might be right there with you. But the overwhelming majority of people I’ve personally seen who try the switch convert within a day, are barely slowed down by day two, and are effectively fluent within three days to a week at most.
It really just depends. I was very comfortable with the git cli. It didn't take long to learn jj's, and I'm faster with it now than I ever was with git, simply because a lot of things are easier to do and take less commands.
With `jjui` this strategy takes only a few keystrokes to do operations like adding/removing parents from merge commits.
It's so nice to have like 4 parallel PRs in flight and then rebase all of them and all the other experimental branches you have on top onto main in 1 command.
Also, I cannot even stress to you how much first-class-conflicts is a game changer. Like seriously you do NOT understand how much better it is to not have to resolve conflicts immediately when rebasing and being able to come back and resolve them whenever you want. It cannot be overstated how much better this is than git.
Also, anonymous branches are SOOOO much better than git stashes.
You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`.
I agree that Git could gain an operation log. I haven't thought much about it but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.
The last one is always available via `git checkout -` and if you want to do more you can do `git checkout @{4}` etc. . It will also show up in `git log --reflog`. I honestly don't see the problem with naming things. Typing a chosen name is just so much more convenient than looking up the commit hash, even when you only need to type the unique prefix. When I don't want to think of a name yet, I just do "git tag a, b, c, ..."
I also tend to have the builtin GUI log equivalent (gitk) open. This has the behaviour, that no commit vanishes on refresh, even when it isn't on a branch anymore. To stop showing a commit you need to do a hard reload. This automatically puts the commit currently selected into the clipboard selection, so all you need to do is press Insert in the terminal.
> It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.
I don't think that needs to be implemented like this. The only thing you need to do is recording the list of commands and program a resolver that outputs the inverse command of any given command.
Yeah but in jj every time you run ‘jj log’ you see all your anonymous branches and you can rebase all of them at once onto main in 1 command.
When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I split a change into 2 commits and branch off the part I like and try something else for the other part. This way of working is not nearly as frictionless with git. A lot of times I do not even bother with editor undo unless it’s just a small amount of undoing because I have this workflow.
Git is to jj like asm is to C: you can do it all with git that you can do with jj but it’s all a lot easier in jj.
I guess I never had complex trees from such an action, just a bunch of parallel branches, but I would say splitting and picking commits from different branches is not exactly hard with git either. Also you can also see them in git, but they won't have change ids of course.
I know how to do everything in git that I can do in jj but the thing is I would never bother doing most of these workflows with git because it’s way more of a pain in the ass than with jj. I work with version control in a totally different way now because how easy jj makes it to edit the graph.
Within a day of switching I was fully up to speed with jj and I never see myself going back. I use colocated repos so I can still use git tools in my editor for blaming and viewing file history.
Sure even rebasing a complex tree in git can be done by creating an octopus merge of all leaf nodes and rebasing with preserve merges but like that’s such a pain.
Mostly, yes. It also covers changes to the working copy (because jj automatically snapshots changes in the working copy). It's also much easier to use, especially when many refs were updated together. But, to be fair, it's kind of hard to update many refs at once with Git in the first place (there's `git rebase --update-refs` but not much else?), so undoing multiple ref-updates is not as relevant there.
The most common reason is that the git user has no idea it exists. I am in this bucket alongside 99% of git users.
There are an assortment of other potential reasons:
- It is a new tool that hasn't been battle tested as much as git has, which can decrease confidence.
- Git has inertia. People have learned it, it takes less effort to add a new git skill to your repertoire than learn a new tool from scratch, even if the new tool is easy to pick up.
- Due to its novelty, the auxiliary tooling ecosystem for jj is smaller (does it have plugins for all the popular editors? Lots of people like those, git's are high quality)
- Git is good enough. It's not perfect, but its popularity means that its shortcomings have readily available fixes or tweaks from users. It simply isn't bad enough and there are bountiful resources on how to use it effectively.
I think a core reason (besides not knowing jj exists), is the framing that there is a choice that has to be made, or a switch that has to occur. It is, instead, additive. I have Sublime Merge (GUI git client) and jj both looking at my git repo all day. Zed's git stuff is watching it too.
jj is sort of a bag of git tricks for me that I use when needed. It's no different than some things being easier with the git CLI vs others being easier in Sublime. I'll be at a stage where my committing/branching/rearranging wants are something that jj nails perfectly, and I do those there. As far at the other tools are concerned, I just did a bunch of sophisticated git operations.
The "colocated with git" capability of jj is probably it's most amazing feature tbh, and is key to any sort of adoption.
I don't think it's pride, more that I don't see the problem that it solves for me. I don't find that git gets in my way at all, and I don't find it confusing. It's a pretty transparent tool that I use every day and hardly notice.
I don't mind other people using jj, but I simply don't feel a need to try it. There's nothing prideful about that, it's just pragmatism.
Pragmatic is using the best tool for the job. Certainly subjectively, and arguably objectively, jj is the better tool in many ways.
My advice is to try it. You should like it, if you're in the majority of folks to give it a sincere shot. If you don't like it, cool. But then my advice changes. jj is probably the future. Adapt or become one of those old-timers who froze their learning in time.
1. It's very new; I haven't had time to learn it properly yet.
2. It's very new and tooling doesn't support it well, e.g. VSCode. There aren't many GUIs yet.
3. I tried it once co-locating with Git and you definitely can't use both at the same time, even if it can use a `.git` directory. It ended up in a huge mess.
I'm definitely in favour of better-than-Git alternatives but I don't think it's reasonable to expect everyone to switch to JJ right now. It isn't so much better that abandoning the de facto standard is obviously worth it yet. (In contrast to things like the iPhone, Rust, SSDs, etc.).
Also I really wish they would focus on some of the bigger pain points of Git. I can deal with rebasing and whatnot. Sometimes it's painful but it's usually not that bad.
What I can't deal with are submodules and LFS. Both are awful and fixing them properly requires fundamental changes to the VCS which aren't going to happen in Git. JJ has an opportunity to do that. Imagine if JJ could say "we have submodules but they aren't awful!" or "you can check in large files!". Those are the sort of huge advantages that would mean you can say "why not just use JJ".
Colocating is the default now, and you should be able to use both at the same time, though running git commands that mutate can confuse jj. Ideally you only use read-only git commands.
Both submodules and LFS are things that jj wants to address, but they take time.
Oh, there's another stgit user! ^5
Coming from darcs, I couldn't use git until stgit came along, and today, it's one of those few tools I can't imagine working without. Nothing else matches my way of code hacking.
So often, I watch people making a big mess with git, and I always recommend stgit to them, so they can post proper and reviewable branches for merging. But in all these years, I could never convince anybody.
It’s a bit like qwertz. Sure, it is not optimal, there are better alternatives available. But it is good enough, and it is universal. That trumps a 5% typing improvement on my own custom keyboard layout at the cost of not being able to use my coworkers keyboard.
Also, I dislike all of the alternate git frontends I tried, because they are opinionated in a way they clash with my workflow.
Moreover, I don’t think the git CLI is that bad. Once you learn some basic concepts, it makes a lot of sense and is pretty consistent.
Most problems people report stem from a refusal to learn the underlying structure and models. That is on them. And when using a different frontend, they don’t disappear either. They are just abstracted, to allow you to avoid learning them. But they are still there, and you will probably still need to know them at some point.
> Most problems people report stem from a refusal to learn the underlying structure and models.
It's very easy to fall into the trap of believing this: git's implementation fits together neatly enough that it feels like the best you could do. Like, yes it's complex, but surely that's just intrinsic complexity of the problem? (Also, I think we all sometimes feel like someone with a different view must just not know as much as us.)
But if you have used other version control systems (I'm thinking particularly Mercurial here) you realise that actually some of that complexity is just totally made up by git.
Jujutsu is not a Git frontend, it is an independent VCS that is compatible with Git. This is important because it has concepts and ideas of its own. It is used entirely independent of Git within Google.
i went from being a "jj cli power user" to relying on jjui for all of my complex rebase needs so quickly that i now have to read the man page to recall basic commands
This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used.
Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature-rich than git. I don't even want to learn another commit graph model, because git's model is very good. About 95% of what people like yourself call "git nonsense" consists of useful features that many people would be annoyed to not have.
I believe that a large number of git or general VCS users have no idea about commit hygiene. They have not had to cherry-pick or edit commits, and have no idea what to do about conflicts. To people like that, git's features and methods will appear especially foreign.
I looked over jj specifically many moons ago and concluded it would annoy me and not function at my job. I forgot what the reasons were. One reason was most likely because I need submodules and worktrees to work. I just looked at its FAQ, and saw a bunch of nonsensical new terms as well. Nothing is more compatible with git than git itself, and I am very satisfied with how well git works for me.
submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support.
worktrees are called "workspaces" in jj, but are the same.
A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.
For me, that's probably jj undo, just because it makes everything else so nice to just give a try. I really don't worry about making mistakes.
But for me, it's not so much features that git doesn't have, it's that the core is factored in a way that's more focused and orthogonal. The stuff that I used to like to do with git is even easier and more straightforward with jj. This is more of the result of a bunch of different design decisions and how they fit together rather than just some specific feature that's great.
Sounds like jj just simplifies the interface of some git commands, mainly. After talking to some jj enthusiasts here, I think we just have a different perspective about what needs to be simple and even what constitutes simple. There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I don't want to teach git to people who are not programmers, but I wouldn't want to teach any programmer's VCS to them honestly. If you are a programmer, I think git is the best.
> There is probably some lingering unfamiliarity with git among jj enthusiasts as well.
I've heard this a few times. But from what I've seen, it seems like often it's the Git enthusiasts who seem to be unfamiliar with jj. I haven't heard from anyone who used jj for a few months and knew it well and then switched to Git.
I have never used jj, nor met anyone who used it in person. Given how new it is, you just won't find enough people who used it at all. I think git is like the vim of VCS systems and like vim there are some people who just don't think that way. I think jj might be more like emacs in that it has the initial appearance of being simple, but when you get into it more deeply you realize that it is not so simple after all.
I have used other VCS systems that made similar claims about being simpler, such as Mercurial. I think I got to be fairly expert at Mercurial before becoming expert at git, and even used it to interact with SVN repositories. (I've also used git for SVN. This is another thing git does better.) After actually learning git past the first few commands, I would never go back to Mercurial. I don't want to mix and match systems either. There are things I want git to do better, but I would not call these simple feature requests... They are more along the lines of advanced features that need to be extended or polished.
I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.
I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this feature, rebasing all the other branches (realistically, probably like 1 or 2) would be easy enough to do manually with the feature described in this post. Rebasing and touching up commits is very easy with git interactive rebase. There are also features to automatically reorder commits with, e. g., `git commit --fixup` and `git rebase --autosquash`.
If you have others in mind then go ahead lol. I was just trying to make it easy.
> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches.
Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script.
I think jj is generally more useful for people like me who often have lots of independent and dependent work in progress. If you mostly just have a one review at a time, there's much less benefit. Perhaps I would say that `jj undo` might be the most useful feature for users with simpler development (yes, I know about the reflog, but see the video I linked to in the other message).
I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately.
If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you start working on the branch again or want to merge them.
--
For me branches also represent features, that should have clear boundaries, so when I work on one feature and that means, I need to rebase another one on top instead of being able to just merge them later, this indicates a spaghetti codebase where the interfaces between features are not properly defined and things depend on internals of other things.
>For me branches also represent features, that should have clear boundaries
I try to do this too but I often end up in situations where I have multiple incomplete (in testing, not merged) features with outstanding patches. Instead of one branch per topic, I end up with one branch for a bunch of related stuff. I then rebase and pause at the feature boundaries to do more testing. Sometimes, if I find myself doing this a lot, I will use the `exec` feature of `git rebase` to automate my testing.
I think rewriting all related branches can cause problems. It would be really weird to do interactively for one thing. The other problem is that you may have unrelated topic branches broken by such a change. If you have a broken patch X that reveals problem Y on branch Z1, but you are working on fixing that on Z2, you may lose your ability to reproduce the Z1 issue if X is fixed on every branch. What if you get conflicts on all those branches? What does this do to the reflog? Yikes! It seems more dangerous than git itself.
These complaints are very niche of course, but the problem of rewriting many branches at once is also very niche. It can cause more problems than it solves.
That sounds real painful and confusing. You could end up with a bunch of conflicts in separate commits, on multiple branches, none of which you actually wanted to modify in the first place.
Someone just told me that if you rewrite a commit that is an ancestor of multiple branches, it will (or can) automatically rewrite all the branches.
What does it even mean to not resolve conflicts? Your branch code and/or history is broken until you come around and fix it? If so, forcing you to fix it immediately is better. Aside from the practical implications of deferring conflict resolution, I just can't think of a reason I would do it in the first place. If a branch can't be rebased with zero work, and I don't have time to do that work, I just don't do the rebase.
Sure, my point is just that if you don’t want history re-written, you just don’t re-write it. If you have multiple descendant branches and for some reason you don’t want the children to move as well, you can move them back. It’s almost the opposite of what the article describes; instead of needing to choose to move children, children move automatically and you move ones you don’t want to back. I’ve never wanted to do this but if it happened it would be easy enough to fix.
It looks like this: when a git rebase would pause the rebase to make your resolve a conflict, jj keeps going. When the rebase finishes, if there are any conflicts, they’re displayed in the log with ?? after their ID. jj won’t let you push a branch with conflicts until the conflict is resolved. You can fix the conflict by either editing that commit directly, or my preferred way, which is to make a new change on top and then squash the resolution back in after you read it over.
So there’s a few thins about why this is useful: because children are also rebased, you can see immediately how much work, if any, you have to do. I have an alias to rebase all open branches on top of trunk, and will often pull trunk, run it, and see if I have any work to do to update them. “Oh, only one of my three branches needs work, I’ll work on the two that are fine first” can happen, and that third can just sit there. Or, as I said before, I could move it back on top of its old base, and the conflict disappears. Or, say I suspected none of them conflict, but all three do, and I don’t want to do it at all right this moment, I’ll just jj undo and they’re all unconflicted and back in place.
(sorry about the formatting here. I guess you'll have to copy & paste it to read it)
What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the changes into D. The descendant commits (E through J) then get automatically rebased and the feature bookmarks/branches get updated.
I didn't follow what you about it other changes needed for updating the ancestor. Can you explain in the context of this example?
So what I am saying is that after you created D', it is true, that you need to run `rebase --onto` in git, while it is automatic in jj. But I think updating feature2 and feature3 is only really necessary to do now, when you want to change something in G-J also. If you don't and it wouldn't cause merge conflicts at all (logical and physical) then you could also just do this when you work on top of H or J the next time, so it wouldn't actually cause any more work in git compared to JJ.
--
The other thing I am saying is that I don't really let features depend on each other, I let them specify the API between them first and then develop them independently. Otherwise it is easy to violate boundaries. So the ideal is that any of G,H and I,J works with D,E,F and vice versa. Of course that is tangential and it doesn't always work that way.
I think you're right about people having trouble with `git reset` but it's really not that hard. There is also the newer `git restore` command which is somewhat easier. There are many individual functions which have an inverse, so the word "undo" might not be a good choice for git. You could make a `git undo` that does the `jj undo` logic with the reflog very easily. I'm not sold on the simplifications yet but to be fair I'm not trying to learn it either lol.
I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do anything with it, then loudly complain about it being tricky. Anything as complicated as version control is going to be tricky if you don't read the manual. I don't think making another tool entirely is the right solution. Perhaps a different set of git porcelain tools could help, or some git aliases. Maybe better documentation too. But some people just can't be pleased.
This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.
> I don't think making another tool entirely is the right solution.
I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).
Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though.
I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. That was a good talk. I would certainly expect someone like that to have a lot of interest and expertise in git. But it seem to me that there is also a potential commercial angle to making a new/alternative VCS.
I looked at the mailing list entry you linked to about `git history` commands and thought to myself, it sounds all wrong and redundant. `git history` sounds like too broad of a name for one thing. I'd want to have it be `git <verb>` instead. All the operations listed can be done with rebase:
- `git history drop`: Instead, rebase interactively and drop one or more commits.
- `git history reorder`: Interactively rebasing makes this work already.
- `git history split`: Insert a pause in the interactive rebase. Do a soft reset or something to the previous commit, and use `git restore` to unstage the changes (there might be a more efficient way to do this in one step, but idk). Then, do `git add -p` to add what you want, commit, as many times as you want to split the patch. Then continue the rebase.
- `git history reword`: There is a reword option in interactive rebase mode, and also a fixup-like option to do it as well if you want to postpone the rebase.
- `git history squash`: Rebase can do this now in multiple ways.
Rebasing is not that hard. It is the Swiss Army knife of VCS tools. Once you realize that you can just break in the middle of a rebase and do nearly anything (except start another rebase), the world is your oyster. We don't need to spam people with many more single-purpose tools. We need people to understand why the way things are is actually pretty damn good already, if only they read the manual.
Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are:
- `git commit --fixup HEAD~3`
- `git rebase --autosquash HEAD~4`
The "less than 2 steps" part comes from fixing up more than one commit having no conflicts before the rebase. It is very common to want to stop or run test scripts at various points in the newly modified history, and rebase can trivially help you automate that (but only if you want).
Rebasing literally just does a sequence of steps in the order you specify. You can make those steps complicated, or not, without learning yet another tool. The complexity that is in the rebase tool is practically all necessary.
After using git for many years, I realize now that a lot of thought went into its design. The way it works, especially with the rebase tool, is superior to having a dozen single-purpose tools.
I don't think this particular thing is against the UNIX philosophy either. All of these operations are intimately related just like the operations that a FTP client might do. I can just imagine someone like you looking at FTP or rsync, and saying "This can be 20 different commands! Why don't they make my particular use case into its own command!" There is a place for that kind of logic, but all of the things jj supporters have proposed to me are way too niche to have their own separate commands. My commit edits are complicated, and `git rebase` makes them super simple.
I didn't know that, but I'm not surprised that this is possible because jj allows you to defer conflict resolution. I for one prefer git's step-by-step rebase model that makes you address conflicts at the time of the rebase. If you aren't ready to address conflicts, you shouldn't be mucking around with the commit history yet. Also, if you turn on rerere, then you can also (usually) avoid fixing the same conflicts multiple times.
I think the issue that wakawaka28 has and I also have is, that I don't think we should have lots of "wizards" for specific high-level operations users want to do. Then we will only end up with hundreds of commands, that all do slightly the same. Also it will train (new) users to complain about adding yet another command to do what they want, instead of letting them learn how to combine the already existing commands.
What we should do instead is provide a bunch of primitives, that as high-level are as possible so to not end up with duplicate commands, which is what git does currently. `git history` as a name is somewhat pointless, since the whole point of git is to produce and modify the history. In that sense `git history` already exists, it is called `git`.
I think the issue newbies have is not that git commands are hard per se, but that they don't think in terms of modifying the graph yet, or that they don't know which primitives are available.
That makes his decisions all the worse and in poor taste IMO, because he ought to know that these use cases are well-covered already. Furthermore, I'm not talking to him. I'm talking to anyone who thinks that his patch was a good idea. I am not going to be dazzled by brand names in this conversation lol.
Lol you could just say you disagree. Is it SO alien to you that users of the most popular VCS in the world might like it the way it is? After arguing with you guys, the only deep fact coming through is that people like you get irrationally optimistic about new tools, after the old favorite doesn't appeal to you for some reason.
Yeah your parent is being combative all over this thread, there’s just no reason for it.
For whatever it’s worth, the general stance of the project and most of the community is “git is good, we like jj more, but you should use whatever you prefer.” Lots of us loved git before jj came along, and there’s a lot of cross pollination between the two projects. I hope your parent takes the feedback and chills out.
There is also mental friction with learning an entirely new tool. `jj` is different enough from `git` that one can't transfer knowledge. Currently the documentation is not good enough to assuage that issue.
Frankly, this is a rather poor, uninformed excuse. Most people who try it grok the concepts in days. And they feel right at home in weeks. That's when you start hearing, "I'll never go back."
Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj:
1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work is the branch, with specifically named branches, my `jj ls` was confusing as hell.
`jj st` might have helped a bit, but there were scenarios where creating an commit would abandon the branch... if i'm reading my post history correctly. My coworker who was more familiar explained my jj problems away with "definitely pre-release software", so at the time neither of us were aware of a workflow which considered branches more core.
Fwiw, I don't even remember when the jj workflow had branches come into play.. but i was not happy with the UX around branches.
2. iirc i didn't like how it auto stashed/committed things. I found random `dbg!` statements could slip in more easily and i had to be on guard about what is committed, since everything just auto pushed. My normal workflow has me purposefully stashing chunks when i'm satisfied with them, and i use that as the visual metric. That felt less solid with jj.
Please take this with a huge grain of salt, this is 10 month old memory i scavenged from slack history. Plus as my coworker was saying, jj was changing a lot.. so maybe my issues are less relevant now? Or just flat out wrong, but nonetheless i bounced off of jj despite wanting to stick with it.
"creating a commit would abandon the branch" is certainly something lost in translation. There are other reasons you may have not liked the UX, largely that if you create branches and then add a bunch of commits after it, the branch head doesn't automatically move by default. There is a config setting you can change if you prefer that, or the `jj tug` alias some people set up.
I more or less use the method described [here](https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `jj bookmark set branch_name -r @`
I might just not be following correctly but committing in git just carries the branch along for the ride, so there's nothing to do in git for this scenario.
IIRC forcing some specific branch name to point to my changes with `jj` was non-obvious and what made me give up and go back to git when I tried it last year.
You are mistaken. In the workflow I described, I am making changes on top of all branches at once and then deciding which branch to send the new commit to. This allows me to make changes simultaneously to both branches without friction.
I already use Graphite today on top of git. Others are using alternatives like Sapling, etc.
To go back to your question around why people still use these workarounds on top of git, it's because the CLI is just one piece of it. With Graphite, I also get a stack-aware merge queue and review dashboard.
Half my team switched to JJ this year, and I do find stacking PRs to be much more pleasant now. We had previously tried out Graphite but it didn't really stick.
I wrote up a little way to use JJ's revsets to make it easy to push an entire stack of branches in one command:
The main issue I kept having when trying to do this with just git is then managing all the branch names to be attached to the right moved commits, so that my stack could be reviewable on github's open PRs.
Does jj help with that at all?
I've experimented a bit with git-town.com (OSS) and now everyone at $DAYJOB uses graphite.com (SaaS) which does that part very well.
It’s one of the core features that rebases, including branch names (bookmarks in jj) work ‘correctly’. You can rebase whole dags, including merges, with multiple named heads with just one jj rebase -b.
note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits.
this is less of a problem if you're more into the 1 change == 1 commit workflow.
This looks like any other git arcane incantation. If this is a common pattern and jj aims to make things easier, should probably be part of the core commands, no?
It's something that makes a specific workflow easier, a lot of folks that use jj don't necessarily use that workflow.
That doesn't mean it couldn't be a core command someday, but given that the alias works well for people, there's not a ton of reason to make a whole new command. You configure the alias and you're off to the races.
`--update-refs` flag helps a lot in vanilla git. That and `--autosquash` should probably be default flags to `git rebase`. I also don't entirely trust rebase without `-i` (`--interactive`), personally. I hear there is talk about shaking up the out-of-the-box default flags in git 3, and I think rebase should especially get new defaults.
I came into the comments specifically to ask if this flag existed. I feel bad that the author developed this whole flow just because they didn't know about this, but that's pretty common with git.
discoverability is a big problem, especially for CLI tools which can't afford to show small hints or "what's new" popups. I myself learned it from someone else, not docs.
update-refs works only in a narrow case when every branch starts form the tip of a previous. Your helper might still be useful if it properly "replants" whole tree keeping its structure.
No, as far as I can tell, it's basically just doing update-refs. But in my defense, I just found out by looking for the option that for some reason my git manpages are from an old version before it was introduced
Running a git command on one branch and multiple branches being affected is really unusual for me! This really does look like it is designed for just this problem, though. Simple overview: https://blog.hot-coffee.dev/en/blog/git_update_refs/
How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":
$ git checkout feature-1
$ git rebase --update-refs main
Successfully rebased and updated refs/heads/feature-1.
Updated the following refs with --update-refs:
refs/heads/feature-2-base
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
I've settled on a workflow that reverses the situation. I simply commit all my work to the main branch and cherry pick commits into temporary feature branches only when submitting PRs.
This way I only need to worry about maintaining a single consistent lineage of commits. I've been using this workflow for about a year now and find it to be much easier than juggling and rebasing feature branches.
Interesting, I'll be sure to check it out. It sounds pretty similar to the tool I built which lets you edit a "plan" in a text editor to assign commits to feature branches - the plan is saved so it can be amended continuously.
I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.
Add `--update-refs` to your interactive rebase and it will give you an easy line to know how many commits to drop because it will add an `update-ref` line for the old branch. You can just easily delete everything up to and including that `update-ref` line and don't have to manually pull up a git log of the other branch to remember which commits already merged.
(Plus, of course, if you have multiple branches stacked, `--update-refs` makes it easier to update all of them if you start from the outermost branch.)
I picked up `--update-refs` to not lose my mind working in squash merge repos. I much prefer merge commits. I often make good, well documented commits and I like having access to the original commits if I need them, so when in a squash merge repo I become a branch hoarder renaming merged branches with a `zoo/` prefix (to drop them low in sort order, among other reasons it is name `zoo/`).
I will often keep experiment branches around and `--update-refs` helps me manage that because if I see commits that might update-ref a `zoo/` branch I know to drop them from the experiment branch.
All of that discovery of already merged commits would be automatic/cheap in rebases with merge commits. I was very frustrated before discovering `--update-refs`. I'm still often frustrated with squash merging, but keeping a large `zoo/` and having `--update-refs` is extra work that almost replicates the experience of just using merge commits in the first place. I don't know why so many think squash merge workflows are "simpler".
I'm a heavy user of git-spice: https://abhinav.github.io/git-spice (created by a former coworker) and can't really go back to a time without it. While still not nearly as good as Facebook's Phabricator, it's probably the best workflow for small, focused stacked PRs you can achieve in a Github / Gitlab based repository.
Even if `--update-refs` didn't exist, my experience is that git can identify duplicate commits produced by rebase, and knows to skip them when rebasing the same commits to the same place again. Am I imagining that?
Even for 'normal' rebases of a multi-commit series (without named feature branches), I habitually use the --onto form. It is simply easier to conceptualise what is happening if one is explicit about the 3 references.
As such, using it for the situation described in the piece then becomes a trivial matter, especially if one also habitually runs a graph viewer - I generally have one or more instances of gitk running all the time.
What I would really like is a Git equivalent to Mercurial's "fold" operation. I usually make a bunch of commits as I work, just as checkpoints, which I then want to turn into a single final commit when it's done, which could be quite some time later, e.g. "started on thing", "broke it", "broke it more", "Add thing to improve foo of bar".
Mercurial's "histedit" command offers two operations to combine the commits: "fold" and "roll", where "fold" brings the earlier commit into the later commit and "roll" does the reverse. The "fold" operation does exactly what I want in this case: It brings all the changes into the final commit from when I actually finished it, using the commit date of that commit.
Git's "rebase -i" command offers "squash" and "fixup" and "fixup -c" and "fixup -C", but they all do the same thing as "roll", i.e. they keep the earliest commit's date, the date when I started working on the thing and not the date when I finished working on it. (So I then cut and paste the correct date and update the commit afterwards. This may not be the best way to do it.)
That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started.
One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too.
At the very least, you can do your hand editing of the commits during the rebase instead of after by switching the earliest commit from "pick" to "edit" to have the full power to amend the commit before it moves on (with `git rebase --continue` when you are satisfied). (Versus "reword" if you just want to change the commit message only.)
Also, instead of naming commits things like "broke it" and "broke it more" an option is to use `git commit --fixup={previous commit hash}`. That auto-generates a "fixup!" name based on the previous commit and auto-marks it as a fixup if you use the `--autosquash` flag to rebase.
I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit.
But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningful as "broke it", actually. Maybe most people wouldn't even bother making these commits – or maybe they would if Git supported "fold".
My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time.
Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces only once they feel complete and start to tell a story. (And in those cases I may use a lot of `git stash -u` and `git stash pop` snapshots, too, especially if I need to switch branches in that worktree.)
Hmm, I may have actually solved my problem. I think what I mostly want to do is this, if I'm working on the "feature-1" branch based on "main":
$ git checkout feature-1
$ git reset main
$ git commit -a -C feature-1@{1}
This squashes all the changes and keeps the date and and message of the final commit on the branch.
Weirdly, although the "-c" and "-C" flags for the fixup operations sound like they should correspond to the same flags for "git commit", which grabs the date along with the message from the specified commit, the fixup flags only affect the message and not the date.
It would be nice if it worked the same for rebase as for commit. Then "fixup -C" would essentially correspond to Mercurial's "fold".
Ah, yeah, that use of `git reset --soft` is how many places do squash merging, so that makes sense. You may want to make sure to include the `--soft` flag explicitly just as a precaution.
Also yeah, I would expect the fixup -c and -C flags to be more aligned with commit in a rebase.
git fixup doesn't take the old commit message either, so I would be not so surprised that it doesn't take the commit message. It is really for preparing to do rebase fixup to the older commit.
I‘m using git machete since a few months to help with the stacking workflow. The nice thing is that it can use the GitHub CLI to manage the resulting PR stacks as well.
This made good sense, though by the time I got to bits saying "that last step is critical. Without it, your next sync will break" and "Don't forget!" I was laughing out loud. I love git :-)
I feel that stacked PR in git should be common knowledge, however many of the documentations are scattered. I found stacked.dev but feels that its not exploring pure-git workflow that well. thats why I tried to collect all of those docs into a single website that's dedicated into that singular workflow. would love to get any feedback:
Stacked commits is awesome, but it sucks that with git you need all these workarounds, and that the servers (GitHub etc) are not designed with that workflow in mind.
I left Google a few months back to work on another project. I missed the internal version control so much that I dropped that other project and am now focused http://twigg.vc
It's very similar to what's used at Meta and Google. Atomic commits, linear history, auto rebase, code review compatible with stacked commits.
Stacking commits lets you do that without having to wait for each change to be reviewed/merged to the main branch before you iterate on top of those changes.
True. I find I rarely need it: standard rebase or merge do the trick. If they don't the review cycle or PR size may be too high. Super rare I need onto. So rare I look up how to do it when I do.
It's such a complicated way to work though, you start another set of changes then you go back addressing comments then you go back updating the stacked branch and you might need to do that few times...
Teams should focus on getting stuff merged in and not create massive PRs that live forever, life becomes so much easier.
I fail to see how it makes it much easier to review a lot of interdependent branches where branch C needs new logic from branch B which needs commits from branch A.
Sounds like a nightmare to me.
This problem isn't specific to cases where you are rebasing "again and again". Just needing to do a single rebase (e.g. prior to opening a PR) for a stacked feature is enough to need a solution.
And, as others have pointed out, the modern solution is `--update-refs`, so there's no need for complicated workflows any more anyway.
If you mean rebasing as each PR in the stack is merged, most Git platforms have the ability to do that automatically.
No, I mean small chunks that are actually merged instead of having a stack of them floating around.
A rebase before a merge can always happen, of course. But there are not stacked commits then it is just a standard rebase of your small chunk and that's it. And this will also have a shorter life than a stack so rebases will be rarer and simpler.
Oh, yes - but this is more about your situation than your style. Sometimes a feature is large and varied enough to beg multiple PRs, yet singular enough that you are not developing them serially (i.e. as you work on later parts, you are changing earlier parts). Most of the time this isn't the case.
My experience is that you should always aim for frequent small commits. This is what continuous integration and trunk-based development advocate and it saves a lot of headaches and the need to come up with "exotic" solutions to problems created by big, long-lived dev branches.
This is quite orthogonal to developing parts serially or not, and it is perfectly fine to change or refactor ealier parts when you work on later parts. Development is an iterative process.
It seems to me that "stacked diffs" are an example of looking for a technical solution to process issue.
It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time.
That's exactly how I've worked for the past decade or so.
This marker branch step feels like a workaround to a missing capability. It's something I can easily see one forgetting especially if they haven't been doing stacked diff workflows regularly.
I agree it seems error prone. I'm not sure if I'm misunderstanding something, but I use `git cherry-pick` when I know I need to move commits around that might have conflicts. The problem with rebase can be that the user doesn't fully understand all the options being applied and end up with a "bad" merge.
I don't usually want to rewrite history. I just want the target branch with all my commits on top (I usually squash the feature branch into one commit anyway). I have yet to run into a situation where this isn't good enough.
If the branch diverges so much and has so many commits that this simpler approach doesn't work, that might not be a git problem, but a project management one. It's still always nice to know git has tools to get me out of a jam.
I’ve been meaning to write this article for a long time @flexdinesh . Thanks for taking the time to share this technique for managing stacked diffs using vanilla git rebase!
Eh I just use `git rebase -i` and delete the commits I don't want. Much easier to think about.
But the real problem with this workflow is that neither Github nor Gitlab support it at all. Not even Forgejo does. Which blows my mind because is such an obvious way to work.
As far as I know only Tangled actually supports it, but unfortunately Tangled is tangled up in its own weird federation ideas. There's no way to privately host it at all.
Is there any reason besides merge commits ending up in history to not do this with merges instead? ie merge main into feature-1, then feature-1 into feature-2.
Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.
They meant merging the other way, i.e. merging the new changes from main into the stacked feature branches.
This is functionally the same as rebasing, except that the new changes show up at the tip of the commit chain rather than the base. And because it doesn't rewrite history you don't need to force-push.
Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?”
You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference).
I’ve wondered if there is a psychological thing here: someone who spent time memorizing all the git nonsense may have some pride in that (which is earned, certainly), that introduces some mental friction in walking away???
I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does.
jj is harder to adopt for people with a thorough mental model of git, because it's harder to accept jj commands at face value. I know it's modifying my git tree, so I feel compelled to grok exactly what it's doing, but that's distracting and time consuming.
People like me should probably trial jj exclusively for two weeks, to shed that antijjotic resistance and form a more clear-headed opinion.
> jj is harder to adopt for people with a thorough mental model of git
No, it really isn’t. I have used git since shortly after it was first released and I’ve written a git implementation.
I switched to jj in one day. And the amount of git arcana I have to keep in working memory is now basically nil. My VCS now works in almost a 1:1 mapping with how my brain wants to interact with my repo rather than having to go through a translation layer.
If you understand what git commands are doing, what jj does is essentially trivial to add to your mental model.
I also get the benefit of being able to use workflows that I always want to use in git but which are an enormous pain in practice. And I get access to wildly powerful new workflows I didn’t even consider because they would be outlandish in git.
Glad you like that I like it!
What I will say is this: there is certainly an adjustment period, and I also totally hear you about how learning internals can be time consuming.
I think you can get a lot of the way there with at least the core concept with something like this, if you'll indulge me:
With git, you build up stuff on your filesystem. You then select which bits go into a diff in your index, and then when you're done, you stamp out a commit.
With jj, you instead start by creating a commit. In this case, it's empty. Then, every time you run a jj command, it does a snapshot, and this produces a new commit. However, because we want to have a stable identifier for a commit, we introduce a new one: the change id. This is basically an alias for the latest commit snapshot that was made. Your git history is just made up of each of these latest commits for each change.
... does that make any sense? Obviously there's more to all of the features than this, but that's sort of the core way that the histories map to each other.
I was in the same position. Then I tried jj. I knew within the day that I wouldn't switch back.
It's not a trick or workaround. It's a very straightforward use of a command flag on one of the most used git commands. It's even conceptually very simple, you're just rebasing a subset of commits of a branch onto a different parent. Anyone who has ever rebased already has a working mental model of this operation. Framing this issue where knowing a single flag on a command every git user uses every day to perform an operation they already broadly understand as some arcane knowledge and 'nonsense' is ridiculous.
> introduces some mental friction in walking away???
I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zero. Switching to jj means learning another tool to achieve similar outcomes on your workflows.
If jj took many weeks of relearning, I might be right there with you. But the overwhelming majority of people I’ve personally seen who try the switch convert within a day, are barely slowed down by day two, and are effectively fluent within three days to a week at most.
It really just depends. I was very comfortable with the git cli. It didn't take long to learn jj's, and I'm faster with it now than I ever was with git, simply because a lot of things are easier to do and take less commands.
But with jj there are better workflows that aren’t really doable with git.
Last time I saw this claimed (maybe from steve's tutorial?) it was just autosquash. Do you have another example?
https://ofcr.se/jujutsu-merge-workflow
With `jjui` this strategy takes only a few keystrokes to do operations like adding/removing parents from merge commits.
It's so nice to have like 4 parallel PRs in flight and then rebase all of them and all the other experimental branches you have on top onto main in 1 command.
Also, I cannot even stress to you how much first-class-conflicts is a game changer. Like seriously you do NOT understand how much better it is to not have to resolve conflicts immediately when rebasing and being able to come back and resolve them whenever you want. It cannot be overstated how much better this is than git.
Also, anonymous branches are SOOOO much better than git stashes.
> Also, anonymous branches are SOOOO much better than git stashes.
You can do anonymous branches in Git as well. I use both for different use cases.
The UX around anonymous branches in git is not nearly as good as jj though.
Also git has no equivalent to the operation log. `jj undo` and `jj op restore` are so sweet.
I can't comment on the UX of jj, but with git you literally just specify the commit, it doesn't feels tedious to me.
> Also git has no equivalent to the operation log.
For easy cases it's just git reset @{1}, but sure the oplog is a cool thing. I think it will be just added to git eventually, it can't be that hard.
You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`.
I agree that Git could gain an operation log. I haven't thought much about it but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.
The last one is always available via `git checkout -` and if you want to do more you can do `git checkout @{4}` etc. . It will also show up in `git log --reflog`. I honestly don't see the problem with naming things. Typing a chosen name is just so much more convenient than looking up the commit hash, even when you only need to type the unique prefix. When I don't want to think of a name yet, I just do "git tag a, b, c, ..."
I also tend to have the builtin GUI log equivalent (gitk) open. This has the behaviour, that no commit vanishes on refresh, even when it isn't on a branch anymore. To stop showing a commit you need to do a hard reload. This automatically puts the commit currently selected into the clipboard selection, so all you need to do is press Insert in the terminal.
> It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.
I don't think that needs to be implemented like this. The only thing you need to do is recording the list of commands and program a resolver that outputs the inverse command of any given command.
Yeah but in jj every time you run ‘jj log’ you see all your anonymous branches and you can rebase all of them at once onto main in 1 command.
When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I split a change into 2 commits and branch off the part I like and try something else for the other part. This way of working is not nearly as frictionless with git. A lot of times I do not even bother with editor undo unless it’s just a small amount of undoing because I have this workflow.
Git is to jj like asm is to C: you can do it all with git that you can do with jj but it’s all a lot easier in jj.
I guess I never had complex trees from such an action, just a bunch of parallel branches, but I would say splitting and picking commits from different branches is not exactly hard with git either. Also you can also see them in git, but they won't have change ids of course.
I know how to do everything in git that I can do in jj but the thing is I would never bother doing most of these workflows with git because it’s way more of a pain in the ass than with jj. I work with version control in a totally different way now because how easy jj makes it to edit the graph.
Within a day of switching I was fully up to speed with jj and I never see myself going back. I use colocated repos so I can still use git tools in my editor for blaming and viewing file history.
Sure even rebasing a complex tree in git can be done by creating an octopus merge of all leaf nodes and rebasing with preserve merges but like that’s such a pain.
isnt jj undo the equivalent of git reflog (+ reset/checkout)?
Mostly, yes. It also covers changes to the working copy (because jj automatically snapshots changes in the working copy). It's also much easier to use, especially when many refs were updated together. But, to be fair, it's kind of hard to update many refs at once with Git in the first place (there's `git rebase --update-refs` but not much else?), so undoing multiple ref-updates is not as relevant there.
“why not just use jj?”
The most common reason is that the git user has no idea it exists. I am in this bucket alongside 99% of git users.
There are an assortment of other potential reasons:
- It is a new tool that hasn't been battle tested as much as git has, which can decrease confidence.
- Git has inertia. People have learned it, it takes less effort to add a new git skill to your repertoire than learn a new tool from scratch, even if the new tool is easy to pick up.
- Due to its novelty, the auxiliary tooling ecosystem for jj is smaller (does it have plugins for all the popular editors? Lots of people like those, git's are high quality)
- Git is good enough. It's not perfect, but its popularity means that its shortcomings have readily available fixes or tweaks from users. It simply isn't bad enough and there are bountiful resources on how to use it effectively.
I think a core reason (besides not knowing jj exists), is the framing that there is a choice that has to be made, or a switch that has to occur. It is, instead, additive. I have Sublime Merge (GUI git client) and jj both looking at my git repo all day. Zed's git stuff is watching it too.
jj is sort of a bag of git tricks for me that I use when needed. It's no different than some things being easier with the git CLI vs others being easier in Sublime. I'll be at a stage where my committing/branching/rearranging wants are something that jj nails perfectly, and I do those there. As far at the other tools are concerned, I just did a bunch of sophisticated git operations.
The "colocated with git" capability of jj is probably it's most amazing feature tbh, and is key to any sort of adoption.
I don't think it's pride, more that I don't see the problem that it solves for me. I don't find that git gets in my way at all, and I don't find it confusing. It's a pretty transparent tool that I use every day and hardly notice.
I don't mind other people using jj, but I simply don't feel a need to try it. There's nothing prideful about that, it's just pragmatism.
Pragmatic is using the best tool for the job. Certainly subjectively, and arguably objectively, jj is the better tool in many ways.
My advice is to try it. You should like it, if you're in the majority of folks to give it a sincere shot. If you don't like it, cool. But then my advice changes. jj is probably the future. Adapt or become one of those old-timers who froze their learning in time.
This is really over the top and unnecessary.
> why not just use jj
1. It's very new; I haven't had time to learn it properly yet.
2. It's very new and tooling doesn't support it well, e.g. VSCode. There aren't many GUIs yet.
3. I tried it once co-locating with Git and you definitely can't use both at the same time, even if it can use a `.git` directory. It ended up in a huge mess.
I'm definitely in favour of better-than-Git alternatives but I don't think it's reasonable to expect everyone to switch to JJ right now. It isn't so much better that abandoning the de facto standard is obviously worth it yet. (In contrast to things like the iPhone, Rust, SSDs, etc.).
Also I really wish they would focus on some of the bigger pain points of Git. I can deal with rebasing and whatnot. Sometimes it's painful but it's usually not that bad.
What I can't deal with are submodules and LFS. Both are awful and fixing them properly requires fundamental changes to the VCS which aren't going to happen in Git. JJ has an opportunity to do that. Imagine if JJ could say "we have submodules but they aren't awful!" or "you can check in large files!". Those are the sort of huge advantages that would mean you can say "why not just use JJ".
Colocating is the default now, and you should be able to use both at the same time, though running git commands that mutate can confuse jj. Ideally you only use read-only git commands.
Both submodules and LFS are things that jj wants to address, but they take time.
`jj` isn't new. It's definitely not *very* new.
There is a vscode jj gui extension
For me, the answer is stgit. https://stacked-git.github.io/
Oh, there's another stgit user! ^5 Coming from darcs, I couldn't use git until stgit came along, and today, it's one of those few tools I can't imagine working without. Nothing else matches my way of code hacking. So often, I watch people making a big mess with git, and I always recommend stgit to them, so they can post proper and reviewable branches for merging. But in all these years, I could never convince anybody.
That's really neat.
It’s a bit like qwertz. Sure, it is not optimal, there are better alternatives available. But it is good enough, and it is universal. That trumps a 5% typing improvement on my own custom keyboard layout at the cost of not being able to use my coworkers keyboard.
Also, I dislike all of the alternate git frontends I tried, because they are opinionated in a way they clash with my workflow.
Moreover, I don’t think the git CLI is that bad. Once you learn some basic concepts, it makes a lot of sense and is pretty consistent.
Most problems people report stem from a refusal to learn the underlying structure and models. That is on them. And when using a different frontend, they don’t disappear either. They are just abstracted, to allow you to avoid learning them. But they are still there, and you will probably still need to know them at some point.
> Most problems people report stem from a refusal to learn the underlying structure and models.
It's very easy to fall into the trap of believing this: git's implementation fits together neatly enough that it feels like the best you could do. Like, yes it's complex, but surely that's just intrinsic complexity of the problem? (Also, I think we all sometimes feel like someone with a different view must just not know as much as us.)
But if you have used other version control systems (I'm thinking particularly Mercurial here) you realise that actually some of that complexity is just totally made up by git.
> It's very easy to fall into the trap of believing this: git's implementation fits together neatly enough that it feels like the best you could do.
I explicitly said that git IS NOT the best we can do. But it is universal and good enough. Not nearly as bad as some people make it out to be.
Jujutsu is not a Git frontend, it is an independent VCS that is compatible with Git. This is important because it has concepts and ideas of its own. It is used entirely independent of Git within Google.
I've never heard of jj before this thread...
jj does not support git submodules, this precludes even a casual use on my own personal repo.
This is one I'm okay with. Git submodules are absolutely awful.
I recognize that some folks are stuck with it, and yeah, in your case jj probably just doesn't make sense. Stay tuned though.
It just means that you use git commands to update your submodules, jj still works for the rest of the repo just fine.
I have a repo where main has no submodules and a branch has submodules. Switching between then breaks everything...
Yeah, this is annoying right now. Someone is actively working on a patch to improve it, though.
For me the answer is lazygit. I rarely use the git cli. I don't want to learn the jj cli and the TUI wrappers for jj seem less polished.
jjui is great, give it a try!
i went from being a "jj cli power user" to relying on jjui for all of my complex rebase needs so quickly that i now have to read the man page to recall basic commands
can confirm jjui is super nice, except I've never been a jj cli power user ;)
This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used.
Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature-rich than git. I don't even want to learn another commit graph model, because git's model is very good. About 95% of what people like yourself call "git nonsense" consists of useful features that many people would be annoyed to not have.
I believe that a large number of git or general VCS users have no idea about commit hygiene. They have not had to cherry-pick or edit commits, and have no idea what to do about conflicts. To people like that, git's features and methods will appear especially foreign.
I looked over jj specifically many moons ago and concluded it would annoy me and not function at my job. I forgot what the reasons were. One reason was most likely because I need submodules and worktrees to work. I just looked at its FAQ, and saw a bunch of nonsensical new terms as well. Nothing is more compatible with git than git itself, and I am very satisfied with how well git works for me.
submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support.
worktrees are called "workspaces" in jj, but are the same.
A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.
What is the most useful feature of jj that you think git doesn't have?
For me, that's probably jj undo, just because it makes everything else so nice to just give a try. I really don't worry about making mistakes.
But for me, it's not so much features that git doesn't have, it's that the core is factored in a way that's more focused and orthogonal. The stuff that I used to like to do with git is even easier and more straightforward with jj. This is more of the result of a bunch of different design decisions and how they fit together rather than just some specific feature that's great.
Sounds like jj just simplifies the interface of some git commands, mainly. After talking to some jj enthusiasts here, I think we just have a different perspective about what needs to be simple and even what constitutes simple. There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I don't want to teach git to people who are not programmers, but I wouldn't want to teach any programmer's VCS to them honestly. If you are a programmer, I think git is the best.
> There is probably some lingering unfamiliarity with git among jj enthusiasts as well.
I've heard this a few times. But from what I've seen, it seems like often it's the Git enthusiasts who seem to be unfamiliar with jj. I haven't heard from anyone who used jj for a few months and knew it well and then switched to Git.
I have never used jj, nor met anyone who used it in person. Given how new it is, you just won't find enough people who used it at all. I think git is like the vim of VCS systems and like vim there are some people who just don't think that way. I think jj might be more like emacs in that it has the initial appearance of being simple, but when you get into it more deeply you realize that it is not so simple after all.
I have used other VCS systems that made similar claims about being simpler, such as Mercurial. I think I got to be fairly expert at Mercurial before becoming expert at git, and even used it to interact with SVN repositories. (I've also used git for SVN. This is another thing git does better.) After actually learning git past the first few commands, I would never go back to Mercurial. I don't want to mix and match systems either. There are things I want git to do better, but I would not call these simple feature requests... They are more along the lines of advanced features that need to be extended or polished.
I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.
I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this feature, rebasing all the other branches (realistically, probably like 1 or 2) would be easy enough to do manually with the feature described in this post. Rebasing and touching up commits is very easy with git interactive rebase. There are also features to automatically reorder commits with, e. g., `git commit --fixup` and `git rebase --autosquash`.
If you have others in mind then go ahead lol. I was just trying to make it easy.
> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches.
Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script.
I think jj is generally more useful for people like me who often have lots of independent and dependent work in progress. If you mostly just have a one review at a time, there's much less benefit. Perhaps I would say that `jj undo` might be the most useful feature for users with simpler development (yes, I know about the reflog, but see the video I linked to in the other message).
I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately.
If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you start working on the branch again or want to merge them.
--
For me branches also represent features, that should have clear boundaries, so when I work on one feature and that means, I need to rebase another one on top instead of being able to just merge them later, this indicates a spaghetti codebase where the interfaces between features are not properly defined and things depend on internals of other things.
>For me branches also represent features, that should have clear boundaries
I try to do this too but I often end up in situations where I have multiple incomplete (in testing, not merged) features with outstanding patches. Instead of one branch per topic, I end up with one branch for a bunch of related stuff. I then rebase and pause at the feature boundaries to do more testing. Sometimes, if I find myself doing this a lot, I will use the `exec` feature of `git rebase` to automate my testing.
I think rewriting all related branches can cause problems. It would be really weird to do interactively for one thing. The other problem is that you may have unrelated topic branches broken by such a change. If you have a broken patch X that reveals problem Y on branch Z1, but you are working on fixing that on Z2, you may lose your ability to reproduce the Z1 issue if X is fixed on every branch. What if you get conflicts on all those branches? What does this do to the reflog? Yikes! It seems more dangerous than git itself.
These complaints are very niche of course, but the problem of rewriting many branches at once is also very niche. It can cause more problems than it solves.
jj doesn't force you to resolve the conflicts immediately, so it'll just show that they're conflicted until you decide you want to go fix them.
That sounds real painful and confusing. You could end up with a bunch of conflicts in separate commits, on multiple branches, none of which you actually wanted to modify in the first place.
It’s not any different than git, the only difference is that you can choose to resolve the conflict when you want, instead of it interrupting rebase.
If you don’t want to modify a branch, then you shouldn’t rebase it, same as git.
Someone just told me that if you rewrite a commit that is an ancestor of multiple branches, it will (or can) automatically rewrite all the branches.
What does it even mean to not resolve conflicts? Your branch code and/or history is broken until you come around and fix it? If so, forcing you to fix it immediately is better. Aside from the practical implications of deferring conflict resolution, I just can't think of a reason I would do it in the first place. If a branch can't be rebased with zero work, and I don't have time to do that work, I just don't do the rebase.
Sure, my point is just that if you don’t want history re-written, you just don’t re-write it. If you have multiple descendant branches and for some reason you don’t want the children to move as well, you can move them back. It’s almost the opposite of what the article describes; instead of needing to choose to move children, children move automatically and you move ones you don’t want to back. I’ve never wanted to do this but if it happened it would be easy enough to fix.
It looks like this: when a git rebase would pause the rebase to make your resolve a conflict, jj keeps going. When the rebase finishes, if there are any conflicts, they’re displayed in the log with ?? after their ID. jj won’t let you push a branch with conflicts until the conflict is resolved. You can fix the conflict by either editing that commit directly, or my preferred way, which is to make a new change on top and then squash the resolution back in after you read it over.
So there’s a few thins about why this is useful: because children are also rebased, you can see immediately how much work, if any, you have to do. I have an alias to rebase all open branches on top of trunk, and will often pull trunk, run it, and see if I have any work to do to update them. “Oh, only one of my three branches needs work, I’ll work on the two that are fine first” can happen, and that third can just sit there. Or, as I said before, I could move it back on top of its old base, and the conflict disappears. Or, say I suspected none of them conflict, but all three do, and I don’t want to do it at all right this moment, I’ll just jj undo and they’re all unconflicted and back in place.
Let's say you have this (modified from `git rebase --help`):
``` A---B---C main \ D---E---F feature1 \ \---G---H feature2 \ \---I---J feature3 ```
(sorry about the formatting here. I guess you'll have to copy & paste it to read it)
What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the changes into D. The descendant commits (E through J) then get automatically rebased and the feature bookmarks/branches get updated.
I didn't follow what you about it other changes needed for updating the ancestor. Can you explain in the context of this example?
So what I am saying is that after you created D', it is true, that you need to run `rebase --onto` in git, while it is automatic in jj. But I think updating feature2 and feature3 is only really necessary to do now, when you want to change something in G-J also. If you don't and it wouldn't cause merge conflicts at all (logical and physical) then you could also just do this when you work on top of H or J the next time, so it wouldn't actually cause any more work in git compared to JJ.
--
The other thing I am saying is that I don't really let features depend on each other, I let them specify the API between them first and then develop them independently. Otherwise it is easy to violate boundaries. So the ideal is that any of G,H and I,J works with D,E,F and vice versa. Of course that is tangential and it doesn't always work that way.
Hacker News doesn't support Markdown, but you can indent lines by two spaces to get it formatted like code: https://news.ycombinator.com/formatdoc
I think you're right about people having trouble with `git reset` but it's really not that hard. There is also the newer `git restore` command which is somewhat easier. There are many individual functions which have an inverse, so the word "undo" might not be a good choice for git. You could make a `git undo` that does the `jj undo` logic with the reflog very easily. I'm not sold on the simplifications yet but to be fair I'm not trying to learn it either lol.
> I don't even want to learn another commit graph model, because git's model is very good.
I agree. That's why jj uses practically the same model. That's how Git can quite easily be used as a backend.
> I just looked at its FAQ, and saw a bunch of nonsensical new terms as well.
Like what? Perhaps we can improve it.
>Like what? Perhaps we can improve it.
I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do anything with it, then loudly complain about it being tricky. Anything as complicated as version control is going to be tricky if you don't read the manual. I don't think making another tool entirely is the right solution. Perhaps a different set of git porcelain tools could help, or some git aliases. Maybe better documentation too. But some people just can't be pleased.
This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.
> I don't think making another tool entirely is the right solution.
I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).
Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though.
I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. That was a good talk. I would certainly expect someone like that to have a lot of interest and expertise in git. But it seem to me that there is also a potential commercial angle to making a new/alternative VCS.
I looked at the mailing list entry you linked to about `git history` commands and thought to myself, it sounds all wrong and redundant. `git history` sounds like too broad of a name for one thing. I'd want to have it be `git <verb>` instead. All the operations listed can be done with rebase:
- `git history drop`: Instead, rebase interactively and drop one or more commits.
- `git history reorder`: Interactively rebasing makes this work already.
- `git history split`: Insert a pause in the interactive rebase. Do a soft reset or something to the previous commit, and use `git restore` to unstage the changes (there might be a more efficient way to do this in one step, but idk). Then, do `git add -p` to add what you want, commit, as many times as you want to split the patch. Then continue the rebase.
- `git history reword`: There is a reword option in interactive rebase mode, and also a fixup-like option to do it as well if you want to postpone the rebase.
- `git history squash`: Rebase can do this now in multiple ways.
Rebasing is not that hard. It is the Swiss Army knife of VCS tools. Once you realize that you can just break in the middle of a rebase and do nearly anything (except start another rebase), the world is your oyster. We don't need to spam people with many more single-purpose tools. We need people to understand why the way things are is actually pretty damn good already, if only they read the manual.
> Rebasing is not that hard.
No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD.
There's simply no excuses for git being this unusable for the very simplest operations I do day to day.
Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are:
- `git commit --fixup HEAD~3`
- `git rebase --autosquash HEAD~4`
The "less than 2 steps" part comes from fixing up more than one commit having no conflicts before the rebase. It is very common to want to stop or run test scripts at various points in the newly modified history, and rebase can trivially help you automate that (but only if you want).
Rebasing literally just does a sequence of steps in the order you specify. You can make those steps complicated, or not, without learning yet another tool. The complexity that is in the rebase tool is practically all necessary.
After using git for many years, I realize now that a lot of thought went into its design. The way it works, especially with the rebase tool, is superior to having a dozen single-purpose tools.
I don't think this particular thing is against the UNIX philosophy either. All of these operations are intimately related just like the operations that a FTP client might do. I can just imagine someone like you looking at FTP or rsync, and saying "This can be 20 different commands! Why don't they make my particular use case into its own command!" There is a place for that kind of logic, but all of the things jj supporters have proposed to me are way too niche to have their own separate commands. My commit edits are complicated, and `git rebase` makes them super simple.
Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.
I didn't know that, but I'm not surprised that this is possible because jj allows you to defer conflict resolution. I for one prefer git's step-by-step rebase model that makes you address conflicts at the time of the rebase. If you aren't ready to address conflicts, you shouldn't be mucking around with the commit history yet. Also, if you turn on rerere, then you can also (usually) avoid fixing the same conflicts multiple times.
The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.
I think the issue that wakawaka28 has and I also have is, that I don't think we should have lots of "wizards" for specific high-level operations users want to do. Then we will only end up with hundreds of commands, that all do slightly the same. Also it will train (new) users to complain about adding yet another command to do what they want, instead of letting them learn how to combine the already existing commands.
What we should do instead is provide a bunch of primitives, that as high-level are as possible so to not end up with duplicate commands, which is what git does currently. `git history` as a name is somewhat pointless, since the whole point of git is to produce and modify the history. In that sense `git history` already exists, it is called `git`.
I think the issue newbies have is not that git commands are hard per se, but that they don't think in terms of modifying the graph yet, or that they don't know which primitives are available.
For what it's worth, I mostly see jj as being to git what you describe in your first few paragraphs. That's why I like it so much.
That makes his decisions all the worse and in poor taste IMO, because he ought to know that these use cases are well-covered already. Furthermore, I'm not talking to him. I'm talking to anyone who thinks that his patch was a good idea. I am not going to be dazzled by brand names in this conversation lol.
This isn't going to be a very HN-like comment. But it's rooted in fact: That is complete nonsense.
Lol you could just say you disagree. Is it SO alien to you that users of the most popular VCS in the world might like it the way it is? After arguing with you guys, the only deep fact coming through is that people like you get irrationally optimistic about new tools, after the old favorite doesn't appeal to you for some reason.
Yeah your parent is being combative all over this thread, there’s just no reason for it.
For whatever it’s worth, the general stance of the project and most of the community is “git is good, we like jj more, but you should use whatever you prefer.” Lots of us loved git before jj came along, and there’s a lot of cross pollination between the two projects. I hope your parent takes the feedback and chills out.
There is also mental friction with learning an entirely new tool. `jj` is different enough from `git` that one can't transfer knowledge. Currently the documentation is not good enough to assuage that issue.
This really isn’t true. All of my git knowledge—except for the CLI flags—is directly useful for jj.
The jj CLI is very easy to grok, even for a seasoned git user. Maybe even especially so for a seasoned git user.
Frankly, this is a rather poor, uninformed excuse. Most people who try it grok the concepts in days. And they feel right at home in weeks. That's when you start hearing, "I'll never go back."
Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj:
1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work is the branch, with specifically named branches, my `jj ls` was confusing as hell.
`jj st` might have helped a bit, but there were scenarios where creating an commit would abandon the branch... if i'm reading my post history correctly. My coworker who was more familiar explained my jj problems away with "definitely pre-release software", so at the time neither of us were aware of a workflow which considered branches more core.
Fwiw, I don't even remember when the jj workflow had branches come into play.. but i was not happy with the UX around branches.
2. iirc i didn't like how it auto stashed/committed things. I found random `dbg!` statements could slip in more easily and i had to be on guard about what is committed, since everything just auto pushed. My normal workflow has me purposefully stashing chunks when i'm satisfied with them, and i use that as the visual metric. That felt less solid with jj.
Please take this with a huge grain of salt, this is 10 month old memory i scavenged from slack history. Plus as my coworker was saying, jj was changing a lot.. so maybe my issues are less relevant now? Or just flat out wrong, but nonetheless i bounced off of jj despite wanting to stick with it.
"creating a commit would abandon the branch" is certainly something lost in translation. There are other reasons you may have not liked the UX, largely that if you create branches and then add a bunch of commits after it, the branch head doesn't automatically move by default. There is a config setting you can change if you prefer that, or the `jj tug` alias some people set up.
Auto-commit is still a thing, but you can regain the stuff you like with a workflow change, this is called the "squash workflow" and is very popular: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
I more or less use the method described [here](https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `jj bookmark set branch_name -r @`
_Every time I see one of these nifty jj tricks or workarounds I find myself wondering, “why not just use git?”_
How would you do this in stock git?
I might just not be following correctly but committing in git just carries the branch along for the ride, so there's nothing to do in git for this scenario.
IIRC forcing some specific branch name to point to my changes with `jj` was non-obvious and what made me give up and go back to git when I tried it last year.
You are mistaken. In the workflow I described, I am making changes on top of all branches at once and then deciding which branch to send the new commit to. This allows me to make changes simultaneously to both branches without friction.
Can you explain how to do same workflow in jj? It would be nice to compare bads and goodies of git/jj
This part:
> You rebase feature-1 onto main:
feature2 moves as well. Basically, the behavior here is just the default.
Google is definitely your friend here. Plenty of tutorials online.
`jj` doesn’t allow temporary files in the repository that aren’t listed in `.gitignore`.
This makes it unusable for me.
There's multiple ways of handling this, depending on what you prefer.
Keeping these things in a private commit is one option.
Configuring auto-tracking to be off is another option.
It does via snapshot.auto-track https://docs.jj-vcs.dev/latest/config/#paths-to-automaticall...
I have one and a half decades of muscle memory burned in with inoremap jj <Esc>`^
It's not something I can just shift away from.
Definitely let your keybinding keep you from trying out and using a fantastic tool.
I already use Graphite today on top of git. Others are using alternatives like Sapling, etc.
To go back to your question around why people still use these workarounds on top of git, it's because the CLI is just one piece of it. With Graphite, I also get a stack-aware merge queue and review dashboard.
Jujutsu comes in handy here for the same usecase:
https://github.com/jj-vcs/jj
https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut...
Also found https://github.com/gitbutlerapp/gitbutler
Half my team switched to JJ this year, and I do find stacking PRs to be much more pleasant now. We had previously tried out Graphite but it didn't really stick.
I wrote up a little way to use JJ's revsets to make it easy to push an entire stack of branches in one command:
https://crabmusket.net/2025/jj-bough-a-useful-alias-for-stac...
The main issue I kept having when trying to do this with just git is then managing all the branch names to be attached to the right moved commits, so that my stack could be reviewable on github's open PRs.
Does jj help with that at all?
I've experimented a bit with git-town.com (OSS) and now everyone at $DAYJOB uses graphite.com (SaaS) which does that part very well.
It’s one of the core features that rebases, including branch names (bookmarks in jj) work ‘correctly’. You can rebase whole dags, including merges, with multiple named heads with just one jj rebase -b.
To expand: In jj, bookmarks point to "changes," not commits. Rebases, history manipulations, etc. preserve change ID, so this "just works."
note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits.
this is less of a problem if you're more into the 1 change == 1 commit workflow.
There's a very common alias `jj tug` for this case:
It moves the nearest bookmark to the commit before the current one (which should be your working commit).This looks like any other git arcane incantation. If this is a common pattern and jj aims to make things easier, should probably be part of the core commands, no?
It's something that makes a specific workflow easier, a lot of folks that use jj don't necessarily use that workflow.
That doesn't mean it couldn't be a core command someday, but given that the alias works well for people, there's not a ton of reason to make a whole new command. You configure the alias and you're off to the races.
Thanks, I replaced my Frankenstein's monster of a parsing pipeline with this, very useful!
There's an experimental-advance-branches feature which helps with that!
`--update-refs` flag helps a lot in vanilla git. That and `--autosquash` should probably be default flags to `git rebase`. I also don't entirely trust rebase without `-i` (`--interactive`), personally. I hear there is talk about shaking up the out-of-the-box default flags in git 3, and I think rebase should especially get new defaults.
I also use these flag when I have the need to, but I very much don't want them to become the default.
That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.
I came into the comments specifically to ask if this flag existed. I feel bad that the author developed this whole flow just because they didn't know about this, but that's pretty common with git.
I'm pretty sure the author was Claude, so don't feel too bad for it.
Thanks. This is going to be so useful, but it pains me to know I could have been using —update-refs for the last three years.
I used to dutifully read release notes for every git release, but stopped at some point. Apparently that point was more than three years ago.
discoverability is a big problem, especially for CLI tools which can't afford to show small hints or "what's new" popups. I myself learned it from someone else, not docs.
I plan to pay it forward today with a post on my work slack. I just need to try it a time or two myself first.
Except they do. You can type <tab>, search the man page or read the release notes. They just don't force the user to.
Exactly, I was reading the blog and wondering the whole time how it's better than --update-refs, which I have been using a lot recently.
Yep. I set this in .gitconfig
I'm guilty lol. I wrote a helper to do rebase chains like this
update-refs works only in a narrow case when every branch starts form the tip of a previous. Your helper might still be useful if it properly "replants" whole tree keeping its structure.
No, as far as I can tell, it's basically just doing update-refs. But in my defense, I just found out by looking for the option that for some reason my git manpages are from an old version before it was introduced
Though at that point it may be easier to rewrite your helper to manage rebase's interactive scripts.
I think ‘git rebase —-update-refs’ is the better way to go for this scenario
Sweet, looks like this is pretty new (2022).
Running a git command on one branch and multiple branches being affected is really unusual for me! This really does look like it is designed for just this problem, though. Simple overview: https://blog.hot-coffee.dev/en/blog/git_update_refs/
It breaks if you amend the top commit instead of adding a new one.
Is there any good guide on how to solve the issue which OP solves?
I was reading this the other day when I came across this feature because I’m stacking PRs recently which I don’t usually do
https://andrewlock.net/working-with-stacked-branches-in-git-...
Another commenter posted this link which was a bit more succinct
https://blog.hot-coffee.dev/en/blog/git_update_refs/
There isn’t much to it though, you just go to the branch and run git rebase with the update refs flag.
You don’t really need docs as --update-refs does what the OP does automatically instead of manually like the OP does.
How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).Presumably I'm doing something wrong?
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
Thanks! Yup, that does the trick.
First, you don't need the extra "marker" commit. This flag obviates the entire workflow.
Second, you run it on the outermost branch: feature 2. It updates all refs in the chain.
I've settled on a workflow that reverses the situation. I simply commit all my work to the main branch and cherry pick commits into temporary feature branches only when submitting PRs.
This way I only need to worry about maintaining a single consistent lineage of commits. I've been using this workflow for about a year now and find it to be much easier than juggling and rebasing feature branches.
In case anyone's interested, I made a tool that automates this workflow. The worfklow and tool are described here: https://github.com/bjvanderweij/dflock/
You might like Jujutsu – you commit without being on any branch and then later you can decide where and how you put things onto branches.
Interesting, I'll be sure to check it out. It sounds pretty similar to the tool I built which lets you edit a "plan" in a text editor to assign commits to feature branches - the plan is saved so it can be amended continuously.
How many people on the team?
I work in a small team, about five people.
GitButler handles all of this pretty automatically, if you don't want to deal with the Git gymnastics needed here.
https://blog.gitbutler.com/stacked-branches-with-gitbutler
I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.
Yeah, I do this too: The `--onto` solution feels a bit too magical at times and an interactive rebase is pretty clear about what's happening.
Add `--update-refs` to your interactive rebase and it will give you an easy line to know how many commits to drop because it will add an `update-ref` line for the old branch. You can just easily delete everything up to and including that `update-ref` line and don't have to manually pull up a git log of the other branch to remember which commits already merged.
(Plus, of course, if you have multiple branches stacked, `--update-refs` makes it easier to update all of them if you start from the outermost branch.)
Nice; thanks :) I usually squash-merge. Does that break this workflow?
Depends on how fast you delete merged branches?
I picked up `--update-refs` to not lose my mind working in squash merge repos. I much prefer merge commits. I often make good, well documented commits and I like having access to the original commits if I need them, so when in a squash merge repo I become a branch hoarder renaming merged branches with a `zoo/` prefix (to drop them low in sort order, among other reasons it is name `zoo/`).
I will often keep experiment branches around and `--update-refs` helps me manage that because if I see commits that might update-ref a `zoo/` branch I know to drop them from the experiment branch.
All of that discovery of already merged commits would be automatic/cheap in rebases with merge commits. I was very frustrated before discovering `--update-refs`. I'm still often frustrated with squash merging, but keeping a large `zoo/` and having `--update-refs` is extra work that almost replicates the experience of just using merge commits in the first place. I don't know why so many think squash merge workflows are "simpler".
I'm a heavy user of git-spice: https://abhinav.github.io/git-spice (created by a former coworker) and can't really go back to a time without it. While still not nearly as good as Facebook's Phabricator, it's probably the best workflow for small, focused stacked PRs you can achieve in a Github / Gitlab based repository.
Even if `--update-refs` didn't exist, my experience is that git can identify duplicate commits produced by rebase, and knows to skip them when rebasing the same commits to the same place again. Am I imagining that?
That works until you had to fix conflicts during the rebase and the commits are no longer identical.
It definitely fast-forwards unchanged commits.
Even for 'normal' rebases of a multi-commit series (without named feature branches), I habitually use the --onto form. It is simply easier to conceptualise what is happening if one is explicit about the 3 references.
As such, using it for the situation described in the piece then becomes a trivial matter, especially if one also habitually runs a graph viewer - I generally have one or more instances of gitk running all the time.
What I would really like is a Git equivalent to Mercurial's "fold" operation. I usually make a bunch of commits as I work, just as checkpoints, which I then want to turn into a single final commit when it's done, which could be quite some time later, e.g. "started on thing", "broke it", "broke it more", "Add thing to improve foo of bar".
Mercurial's "histedit" command offers two operations to combine the commits: "fold" and "roll", where "fold" brings the earlier commit into the later commit and "roll" does the reverse. The "fold" operation does exactly what I want in this case: It brings all the changes into the final commit from when I actually finished it, using the commit date of that commit.
Git's "rebase -i" command offers "squash" and "fixup" and "fixup -c" and "fixup -C", but they all do the same thing as "roll", i.e. they keep the earliest commit's date, the date when I started working on the thing and not the date when I finished working on it. (So I then cut and paste the correct date and update the commit afterwards. This may not be the best way to do it.)
That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started.
One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too.
At the very least, you can do your hand editing of the commits during the rebase instead of after by switching the earliest commit from "pick" to "edit" to have the full power to amend the commit before it moves on (with `git rebase --continue` when you are satisfied). (Versus "reword" if you just want to change the commit message only.)
Also, instead of naming commits things like "broke it" and "broke it more" an option is to use `git commit --fixup={previous commit hash}`. That auto-generates a "fixup!" name based on the previous commit and auto-marks it as a fixup if you use the `--autosquash` flag to rebase.
I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit.
But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningful as "broke it", actually. Maybe most people wouldn't even bother making these commits – or maybe they would if Git supported "fold".
My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time.
Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces only once they feel complete and start to tell a story. (And in those cases I may use a lot of `git stash -u` and `git stash pop` snapshots, too, especially if I need to switch branches in that worktree.)
Hmm, I may have actually solved my problem. I think what I mostly want to do is this, if I'm working on the "feature-1" branch based on "main":
This squashes all the changes and keeps the date and and message of the final commit on the branch.Weirdly, although the "-c" and "-C" flags for the fixup operations sound like they should correspond to the same flags for "git commit", which grabs the date along with the message from the specified commit, the fixup flags only affect the message and not the date.
It would be nice if it worked the same for rebase as for commit. Then "fixup -C" would essentially correspond to Mercurial's "fold".
Ah, yeah, that use of `git reset --soft` is how many places do squash merging, so that makes sense. You may want to make sure to include the `--soft` flag explicitly just as a precaution.
Also yeah, I would expect the fixup -c and -C flags to be more aligned with commit in a rebase.
git fixup doesn't take the old commit message either, so I would be not so surprised that it doesn't take the commit message. It is really for preparing to do rebase fixup to the older commit.
If you ever try out jj, both fold and roll exist as `jj squash`. You'd choose as the destination the change of the time you'd want to keep.
You could use "git reset --soft oldest-commit" and then "git commit -C newest-commit".
I‘m using git machete since a few months to help with the stacking workflow. The nice thing is that it can use the GitHub CLI to manage the resulting PR stacks as well.
https://github.com/VirtusLab/git-machete
This made good sense, though by the time I got to bits saying "that last step is critical. Without it, your next sync will break" and "Don't forget!" I was laughing out loud. I love git :-)
I feel that stacked PR in git should be common knowledge, however many of the documentations are scattered. I found stacked.dev but feels that its not exploring pure-git workflow that well. thats why I tried to collect all of those docs into a single website that's dedicated into that singular workflow. would love to get any feedback:
https://stacked-pr.github.io
(disclaimer: partly supported by AI, but most of the writing structure were made by hand)
If you adopt a good continuois integration process you don't need stacked commits at all, which are more a symptom of a process issue, IMHO.
It's fashionable at the moment so there is a bit of herd mentality going on. In 2 years they'll be a reinvention of the wheel again against it.
Stacked commits is awesome, but it sucks that with git you need all these workarounds, and that the servers (GitHub etc) are not designed with that workflow in mind.
I left Google a few months back to work on another project. I missed the internal version control so much that I dropped that other project and am now focused http://twigg.vc It's very similar to what's used at Meta and Google. Atomic commits, linear history, auto rebase, code review compatible with stacked commits.
Fun stuff, but I'll stick to trunk based dev, small PRs... thanks!
Stacking commits lets you do that without having to wait for each change to be reviewed/merged to the main branch before you iterate on top of those changes.
True. I find I rarely need it: standard rebase or merge do the trick. If they don't the review cycle or PR size may be too high. Super rare I need onto. So rare I look up how to do it when I do.
It's such a complicated way to work though, you start another set of changes then you go back addressing comments then you go back updating the stacked branch and you might need to do that few times... Teams should focus on getting stuff merged in and not create massive PRs that live forever, life becomes so much easier.
Hard part is keeping the feature branches orthogonal and maintaing all the -base branches. Every fixup commit would invalidate them.
I fail to see how it makes it much easier to review a lot of interdependent branches where branch C needs new logic from branch B which needs commits from branch A. Sounds like a nightmare to me.
People should really try to work on trunk.
Instead of "stacked diffs", isn't the more "continuous integration" solution to split a big feature into small chunks that actually get merged?
Having to rebase again and again is a symptom that a dev branch is living for too long.
This problem isn't specific to cases where you are rebasing "again and again". Just needing to do a single rebase (e.g. prior to opening a PR) for a stacked feature is enough to need a solution.
And, as others have pointed out, the modern solution is `--update-refs`, so there's no need for complicated workflows any more anyway.
If you mean rebasing as each PR in the stack is merged, most Git platforms have the ability to do that automatically.
No, I mean small chunks that are actually merged instead of having a stack of them floating around.
A rebase before a merge can always happen, of course. But there are not stacked commits then it is just a standard rebase of your small chunk and that's it. And this will also have a shorter life than a stack so rebases will be rarer and simpler.
Oh, yes - but this is more about your situation than your style. Sometimes a feature is large and varied enough to beg multiple PRs, yet singular enough that you are not developing them serially (i.e. as you work on later parts, you are changing earlier parts). Most of the time this isn't the case.
My experience is that you should always aim for frequent small commits. This is what continuous integration and trunk-based development advocate and it saves a lot of headaches and the need to come up with "exotic" solutions to problems created by big, long-lived dev branches.
This is quite orthogonal to developing parts serially or not, and it is perfectly fine to change or refactor ealier parts when you work on later parts. Development is an iterative process.
It seems to me that "stacked diffs" are an example of looking for a technical solution to process issue.
I’m amazed that this comment is so low down
Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP
Absolutely everything gets easier when you lower your work in progress.
This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.
> It's very normal to be working on a feature that depends on a not-yet-merged feature.
Oh sure, many bad ideas and poor practises such as that one are quite "normal". It's not a recommendation.
I invite you to look into feature flagging.
It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time.
That's exactly how I've worked for the past decade or so.
[dead]
I believe the author would love stg: https://stacked-git.github.io/guides/tutorial/#patches
For the example given, would merging branch 2 into branch 1 then branch 1 into main achieve the same effect?
Perhaps not an option if you need to release the work in branch 1 before the work in branch 2 is ready/reviewed/etc.
The point of this technique is to keep them separate. See the other comments about `--update-refs`.
This marker branch step feels like a workaround to a missing capability. It's something I can easily see one forgetting especially if they haven't been doing stacked diff workflows regularly.
The capability is there.
Just use git rebase --update-refs ...
Wow you aren't wrong, the first blog post on Google talking about this is exactly what this complicated method does just built-in.
To be fair --update-refs was only added in git 2.38 (released in 2022) so it’s likely that OPs workflow came about before this flag was introduced.
I agree it seems error prone. I'm not sure if I'm misunderstanding something, but I use `git cherry-pick` when I know I need to move commits around that might have conflicts. The problem with rebase can be that the user doesn't fully understand all the options being applied and end up with a "bad" merge.
I don't usually want to rewrite history. I just want the target branch with all my commits on top (I usually squash the feature branch into one commit anyway). I have yet to run into a situation where this isn't good enough.
If the branch diverges so much and has so many commits that this simpler approach doesn't work, that might not be a git problem, but a project management one. It's still always nice to know git has tools to get me out of a jam.
Rebase is just automated cherry-pick, so it ends being the same. The pick command in rebase is exactly that.
> and end up with a "bad" merge.
They end up with exactly the same merge when using cherry-pick directly?
> I don't usually want to rewrite history. I just want the target branch with all my commits on top
That's ... what rewriting history is?
I’ve been meaning to write this article for a long time @flexdinesh . Thanks for taking the time to share this technique for managing stacked diffs using vanilla git rebase!
I consider myself a shmedium experienced dev who likes to learn their tools and read source.
This seems like a house of cards whose juice isn’t worth the squeeze. But I would love to split up my PRs into smaller pieces.
I just would hate to waste time with an incomprehensibly goofed git history because I forgot a command.
We use graphite at work to automate this workflow. The whole point is avoid this toil.
Ah, I've been doing this for ages but apparently this practice has a name
Eh I just use `git rebase -i` and delete the commits I don't want. Much easier to think about.
But the real problem with this workflow is that neither Github nor Gitlab support it at all. Not even Forgejo does. Which blows my mind because is such an obvious way to work.
As far as I know only Tangled actually supports it, but unfortunately Tangled is tangled up in its own weird federation ideas. There's no way to privately host it at all.
I’m not sure what you mean, I stack PRs all the time with GitHub - select the earlier branch as the merge target instead of the main branch.
That doesn't work for cross-repo PRs which is by far the most common way of creating PRs on GitHub (at least for open source stuff).
Is there any reason besides merge commits ending up in history to not do this with merges instead? ie merge main into feature-1, then feature-1 into feature-2.
Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.
The use case is that they are not ready to merge yet.
They meant merging the other way, i.e. merging the new changes from main into the stacked feature branches.
This is functionally the same as rebasing, except that the new changes show up at the tip of the commit chain rather than the base. And because it doesn't rewrite history you don't need to force-push.