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

Jujutsu megamerges for fun and profit

isaaccorbrey.com

Post reply on HN
Print view View original

151–160 of 175 posts

Re: Jujutsu megamerges for fun and profit

#151

Post by ksymph »

incognito124 wrote: post #89
ksymph wrote: post #43

Semi off-topic, but does anyone know of good resources for jj that don't assume git knowledge? Steve's and others are high quality, but often things are explained in terms of git equivalents or describe workflows that I struggle to fully understand the purpose of, as someone who knows only the barest basics of git necessary to work on personal projects. If none exist, I think there's a great opportunity there, for an…

There's https://jj-for-everyone.github.io/

> This is a tutorial for the Jujutsu version control system. It requires no previous experience with Git or any other version control system.

> At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This tutorial is my attempt to fill the void of beginner learning material for Jujutsu.

Exactly what I was looking for, thank you!

Re: Jujutsu megamerges for fun and profit

#152

Post by eddd-ddde »

chrishill89 wrote: post #91

Sometimes I have several pull requests to review and none of them have any meaningful overlap (e.g. they touch code in different places, no apparent risk of overlap). So I've started making integration branches to test all of them in one go. But then I sometimes find things to improve upon. Then I might make a few commits on top of that. And then later I have to manually move them to the correct branch. I might also…

With JJ I sometimes make a 'jj new a b c' to work on top of multiple changes. Then as I tweak things 'jj absorb' to automatically patch the right changes.

Insanely easy and effective.

Re: Jujutsu megamerges for fun and profit

#153

Post by SOLAR_FIELDS »

chrishill89 wrote: post #103
SOLAR_FIELDS wrote: post #76

Earlier quoted context omitted.

Every time I hear about this megamerge and stacked pr nonsense, it just smells to me. Like, why does your engineering organization have a culture where this sort of nonsense is required in the first place? Anytime I see articles like this gushing about how great tool XYZ is for stack merging and things like that, all I hear is "you don't have a culture where you can get someone looking at and mainlining your PR on th…

Not all software is developed by one software organization. Programs to manage “stacks of patches” go back decades. That might be hundreds that have accumulated over years which are all rebased on the upstream repository. The upstream repository might be someone you barely know, or someone you haven’t managed to get a response from. But you have your changes in your fork and you need to maintain it yourself until ups…

Makes total sense! But what you described is like less than 5% of the use case here. Right tool for the right job and all that, what doesn't make sense is having this insanity in a "normal" software engineering setup where a single company owns and maintains the codebase, which is the vast majority of use cases.

Re: Jujutsu megamerges for fun and profit

#154

Post by nozzlegear »

rstuart4133 wrote: post #126
nozzlegear wrote: post #49

Earlier quoted context omitted.

I've found agents like Claude are absolute ass at fixing any halfway complex merge conflict. I won't trust them to do it.

You trust Claude (or any AI) to do anything right? The odds are good - but never 100%. That said, "jj new -A @", get Claude to do it's thing, "jj squash" is going to be pretty safe.

No, I don't trust AI to do much of anything. I've written in other comments on HN that I mostly use it to write draft commit messages and pull requests that I review and rewrite myself, now that the honeymoon phase has ended. But when I was still attempting to get it to do more, I found Claude Code was really bad at trying to fix conflicted merges and rebases, always dropping the wrong parts of the code and leaving me with a broken codebase and a commit message history that didn't make sense for the changes inside.

Re: Jujutsu megamerges for fun and profit

#155

Post by seba_dos1 »

jychang wrote: post #107
stouset wrote: post #84

Earlier quoted context omitted.

I don't get git. Every time it's posted people gush about how git enables some super complicated workflow that I can't wrap my head around. I have a simple edit/undo workflow in my editor that has served me well for decades so I guess I don't understand...

If you think about it, git is really just a big undo/redo button and a big "merge 2 branches" button, plus some more fancy stuff on top of those primitives.

"Merge 2 branches" is already far from being a primitive. A git repository is just a graph of snapshots of some files and directories that can be manipulated in various ways, and git itself is a bunch of tools to manipulate that graph, sometimes directly (plumbing) and sometimes in an opinionated way (porcelain). Merging is nothing but creating a node (commit) that has more than one parent (not necessarily two) combined with a pluggable tool that helps you reconcile the contents of these parents (which does not actually have to be used at all as the result does not have to be related to any of the parents).

(you may know that already, but maybe someone who reads this will find this helpful for forming a good mental model, as so many people lack one despite of working with git daily)

Re: Jujutsu megamerges for fun and profit

#157

Post by seba_dos1 »

locknitpicker wrote: post #129
surajrmal wrote: post #75

Earlier quoted context omitted.

If you wrangle a lot of in flight changes that are not yet merged into your teams primary git repo, it's very helpful. I have some 10-30 changes in various states at any time. Sometimes they have dependencies on each other sometimes they don't. Placing them all into one branch can work but it's a lot less ergonomic in many ways. jj makes my life simpler because it accommodates my workflow in a way git doesn't. Honest…

> I have some 10-30 changes in various states at any time. Sometimes they have dependencies on each other sometimes they don't. This is the sort of scenario that leans me towards thinking tools are being praised by how they support major red flags in development flows. Having dozens of changes in flight in feature branches that may or may not be interdependent is a major red flag. Claiming that a tool simplifies mana…

Some will say that it's a "red flag", others will say that those saying it's a red flag lack the experience of working on diverse set of projects with various needs and requirements.

Re: Jujutsu megamerges for fun and profit

#158

Post by seba_dos1 »

dwb wrote: post #136
SOLAR_FIELDS wrote: post #80

Earlier quoted context omitted.

All fair points, indeed I face each of the challenges you listed periodically myself. But it's never been often enough to feel like I need to seek out an entirely different toolchain and approach to manage them.

Well, fortunately Jujutsu isn’t an entirely different toolchain and/or approach. It’s one tool that’s git-compatible and is quite similar to it. But where it’s different, it’s (for me) better.

Yeah, I've never used Jujutsu, but from what I've seen so far everything it does can be done with Git itself, just perhaps in a (sometimes significantly) less convenient way.

Re: Jujutsu megamerges for fun and profit

#159

Post by seba_dos1 »

vaylian wrote: post #94

One of the golden rules of git is: Don't rewrite public history (for example by rebasing and force-pushing already published commits). The article hints at immutable and mutable commits ( https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an... ) but I am unsure about how fundamental this protection is. I don't want to ruin my co-worker's day by accidentally rewriting public history.

More like a custom which sometimes has good reasons to be broken than a golden rule. A branch in Git is nothing but a pointer to a commit, anything more than that is social agreement that can differ in various contexts.
Post reply on HN