Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defeating Git Rigour Fatigue with Jujutsu

ikesau.co

Post reply on HN
Print view View original

81–90 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#81

Post by NamlchakKhandro »

y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

Feel the same way about JJ.

It feels like Apple vs Linux. Apple being different ... just because (it gives them an artificial moat)

Re: Defeating Git Rigour Fatigue with Jujutsu

#82

Post by paradox460 »

nextaccountic wrote: post #55

> 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

Jj could do that; it stores an evolog of each change, but currently that's kept local

Re: Defeating Git Rigour Fatigue with Jujutsu

#83

Post by NamlchakKhandro »

BobbyTables2 wrote: post #56

I don’t understand. Are there people that try to use git without ever invoking “git rebase -i” ?

Yes. almost the majority of git users do this. i would say that as an expert commenter, 99.9% of people outside of California do this.

Re: Defeating Git Rigour Fatigue with Jujutsu

#85

Post by kccqzy »

y1n0 wrote: post #73
kccqzy wrote: post #63

Earlier quoted context omitted.

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…

Yeah, I don't get it. I'm sure it's because we work differently and that's fine. But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that eve…

I collaborate a whole lot. In fact for solo development I use git because jj is overkill for it. Also by default jj prevents you from overwriting commits that exists on the main branch on the remote, but this is what I often do on solo projects.

> having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters

In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.

Re: Defeating Git Rigour Fatigue with Jujutsu

#86

Post by Macha »

nine_k wrote: post #32
jolux wrote: post #10

Earlier quoted context omitted.

I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new ` and you have a new branch. Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?

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 contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires.

Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.

Re: Defeating Git Rigour Fatigue with Jujutsu

#87

Post by dzaima »

kccqzy wrote: post #63
y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…

But you probably haven't spent time writing commit messages before a branch is finished. Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change; replacing a chore with a much bigger chore.

Restricted and summarized is good - easier to find/remember, less fluff in a list. And easier to recognize a short identifier from a list of the 2-3 most recent branches, than scanning through 50 commits, when trying to remember where some work last was, and which is the proper end-point instead of some failed attempt or unrelated change.

Unnamed branches are quite neat - I certainly have a lot more of such than named ones in jj - but as such named branches are, if anything, more important as a result, for separating sequences of changes striving towards a goal, from the sea of smaller experiments.

Re: Defeating Git Rigour Fatigue with Jujutsu

#88

Post by kccqzy »

dzaima wrote: post #87
kccqzy wrote: post #63

Earlier quoted context omitted.

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…

But you probably haven't spent time writing commit messages before a branch is finished. Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change; replacing a chore with a much bigger chore. Restricted and summarized is good - easier to find/remember, less fluff in a list. And easier to recognize a short identifier from a list of the 2-3 most recent b…

> But you probably haven't spent time writing commit messages before a branch is finished.

Wrong. With jj, I use `jj describe` before I start work. It is like writing out a plan for what I want to do.

> Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change.

Rewriting it is not wasted time. It is an opportunity to look at what I have written in the plan and check whether I have really executed them, and then rephrase things to be more easily understandable.

> Restricted and summarized is good - easier to find/remember, less fluff in a list.

The first line of a commit message is already a summary of the work done. And you can use actual English instead of trying to awkwardly avoid spaces in your words.

Re: Defeating Git Rigour Fatigue with Jujutsu

#89

Post by Macha »

y1n0 wrote: post #73
kccqzy wrote: post #63

Earlier quoted context omitted.

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…

Yeah, I don't get it. I'm sure it's because we work differently and that's fine. But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that eve…

When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.

Re: Defeating Git Rigour Fatigue with Jujutsu

#90

Post by Macha »

nomel wrote: post #7
mi_lk wrote: post #5

So: Squash everything together then pick each component out by squash -i to an empty commit. Seems straightforward, wouldn’t call it special

I think jj will never gain momentum because people only have a git mental model at this point, so won't be able to effectively reason about jj.

Having been often called by coworkers to assist them with their git problems, I can assure you they don’t have a git mental model.
Post reply on HN