[flagged]
You can also have you agent use jj with this skill https://github.com/danverbraganza/jujutsu-skill
Wow, that's really nice. I'm absolutely stealing that. Thanks!
Defeating Git Rigour Fatigue with Jujutsu
111–120 of 193 posts
Re: Defeating Git Rigour Fatigue with Jujutsu
#112Earlier quoted context omitted.
I’ll be honest, as a long-time jj user, I actually haven’t the foggiest what you’re talking about with branches being laborious to keep up to date. Can you elaborate?
I make a commit and the branch doesn't follow it. Bookmark, whatever. That is never a behavior I would want. What purpose does it serve?
Of all the things I was imagining it might be, this was down at the bottom.
Personally I’m a huge fan of this approach. If you aren’t, it’s literally just a one-liner (that is trivially made into an alias) to advance a branch name to the most recent revision. And now there’s a feature to do auto-advancing if you want it.
Why is it this way? Because jj is designed around revisions being constantly mutated.
In git, when I make a commit, I am typically signaling that that a chunk of work is complete. Not always, but usually. In most jj workflows, revisions are mutated constantly during development. A revision being made on the tip of a branch is rarely a signal that that unit of work is finished. It’s even incredibly common to have multiple revisions in a row that are works in progress. Hell, the article we’re all commenting on discusses just such a workflow. If I make five revisions on top of some branch, there is no reason to assume that any of them are ready to be shared, much less all of them.
Because of that difference, it makes sense to have an explicit act to move a branch name forward.
Re: Defeating Git Rigour Fatigue with Jujutsu
#113Earlier quoted context omitted.
I can, but I don’t need to. jj has nothing I need, so it would be changes for the sake of changes. I’m not saying it’s bad, but people do need to realize that their struggles are theirs, not the whole world.
Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win. It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list. Actually I think that property is a much bigger obstacle to ad…
I use magit on a daily basis. And I do use tig occasionally (I don't like lazygit). Most of my magit workflows only requires a handful of keys (most are only two keys). If you've not tried Magit before, it's like vim for a git repo. tig is more barebones, but I could quickly configure it to be able to do most of the magit tricks I need.
Git cli is tedious. But like all cli operations the goal is always to script your workflow or alias the most used commands in something shorter. I'm sure that jj may have an easier learning curve. But some people do know how git works and like the level of control over commits.
Re: Defeating Git Rigour Fatigue with Jujutsu
#114Earlier quoted context omitted.
I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?
The conflict markers are a first-class citizen in the repo. jj tells you when a commit has a conflict, and you can go edit it at your leisure. It also does prevent you from doing some things with branches in a conflicted state, like pushing them. You might not think this is that big a deal, but this also means you don’t have to resolve the entire thing in one go. Plenty of times with complicated rebases in git, I’ve…
I've come to the opinion that conflicts should be committed and merge fixes should be in another commit afterwards. Arguably even if the merge fix is trivial.
Re: Defeating Git Rigour Fatigue with Jujutsu
#115> Latter commits overwrite work that was done in earlier commits and the story breaks. > Some people prefer this, as it helps git bisect work better. Debuggability versus reviewer convenience is the tradeoff, I guess. Ideally we would have a VCS that made ergonomic to store both history-as-it-happened for some purposes, and the cleaned up, squashed and rebased history for other purposes, ensuring they match
I think that version control has reached a point where the next major evolutionary steps will be based on making history totally shared and immutable with history edits themselves being non-destructive versioned operations that can be browsed as higher order history.
Re: Defeating Git Rigour Fatigue with Jujutsu
#116Earlier quoted context omitted.
This. I feel jj is some years too late. It tries to solve a human problem in an LLM era. LLMs are destined to overcome humans in code merging and change versioning (already did for me). There's little point to introducing yet another layer of indirection when LLMs just cut to the chase.
A lot of humans don't currently trust agents to touch VCS today. I also find that my agent tends to be much better about dealing with jj than it is with git.
Culture change is hard.
A lot of humans still don't use git too.
Many do only when they are forced.
And it's much easier for a professional to be forced to use LLMs than jj when it comes to versioning assist (not even comparable in mindshare but the obvious needs to be said sometimes).
So unfortunately I'm afraid jj is not going to achieve critical mass before 99.99% of merges are done by AI which don't need jj.
Re: Defeating Git Rigour Fatigue with Jujutsu
#117Earlier quoted context omitted.
> it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.
that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them. so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
When I'm working in git, I always start work by creating a new branch with a name. Sometimes the branch becomes something different as I work and then I might rename it or more often just keep a stale name around. But in git commit descriptions come later.
In jj, it's the opposite. I start with a change, and I often describe it right away. Branches (bookmarks) come at the end.
You could, in jj, tag a new empty change with a bookmark as soon as you create it. You don't have to advance the bookmark -- that the first change in a sequence of changes is tagged with a bookmark is probably as much information as you need?
Re: Defeating Git Rigour Fatigue with Jujutsu
#118Earlier quoted context omitted.
Imagine that you use jj, while everyone else who works on the repo along with you uses regular git. Is it easy?
The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually…
Are you me? I do feel like I'm starting to forget git as a result of my happy jj use. Thankfully some repos use git submodules, which keeps me at least a little connected
Re: Defeating Git Rigour Fatigue with Jujutsu
#119Earlier quoted context omitted.
> it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.
that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them. so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
[deleted]
Re: Defeating Git Rigour Fatigue with Jujutsu
#120I don’t understand. Are there people that try to use git without ever invoking “git rebase -i” ?
I've done both the rebase and the merge flows in different jobs.
I just don't see the fuss about rebase. Merging just works fine.
Edit: OK, I realized later that I'm not really responding to the usual git rebase -i use case.
Have you heard people say that because of magit they started using more "advanced" git workflows, and how they emphasize having a better UI makes a difference?
It's the same idea with jujutsu. I'm much more likely to use git's power via jujutsu than directly with git. It's because jujutsu lets you do it all with a much simpler interface - fewer commands, and fewer concepts. And knowing that "jj undo" has your back.
As a sibling commenter said: Likely 99% of git users don't do "git rebase -i". But the percentage who do similar with jujutsu is high - perhaps over half[1] of jujutsu users do the equivalent of "git rebase -i" all the time. Many of them didn't when they used git.
The interface matters.
[1] If you told me 80%, it wouldn't surprise me in the least.