Jujutsu at Google [video]

Post by verdverm » Thu, Oct 30, 2025, 9:52 PM UTC

gpm wrote: post #51

shmichael wrote: post #45

I'm trying to understand, would jj's first class conflicts solve the issue of having "stacks" of PRs that can easily be updated at any point in the stack? This is one of the features most absent from git, but prevalent in Google's tooling as well as Meta's. The only good known solution I know is graphite.dev

Not 100% sure I understand what you're saying, but I think the answer is "yes". You can modify any* commit in `jj` regardless of whether it has commits on top of it at any time. Either by another commit into it, or by directly checking out the commit and editing the source tree. If this creates conflicts with commits on top of it `jj` just records those commits as having conflicts/adds conflict markers without interr…

Post by phyrex » Thu, Oct 30, 2025, 9:53 PM UTC

ffsm8 wrote: post #28

phyrex wrote: post #21

Earlier quoted context omitted.

Not to be a jerk, but 'hundreds of devs and dozens of MR per day' is not 'huge repos'. Certain functionality only becomes relevant at scale, and what is easy on a repo worth hundreds of megabytes doesn't work anymore once you have terabytes of source code to deal with.

> terabytes of source code You sure that exists? Git repositories that contain terabytes of source code? I could imagine a repo that is terabytes but has binaries committed or similar... But source code?

Post by martinvonz » Thu, Oct 30, 2025, 9:55 PM UTC

pinkmuffinere wrote: post #29

martinvonz wrote: post #10

Earlier quoted context omitted.

Thanks for the link. I went through it but I'm not sure what it's telling me to change. Can you elaborate? If it's "be more engaging", i think is unfortunately going to be hard to improve because this is just how i am.

I appreciate your frank oppenness to feedback! I'd like to give you some, but first I want to call out that (1) I'm certainly no expert and (2) you may have been voluntold to make a powerpoint on material that isn't well-fit for powerpoint. My feedback: - I think you could improve by being more excited / exciting (the Death By Powerpoint slide deck says "passionate"). Personally, I try to mitigate this problem by dri…

Post by vlovich123 » Thu, Oct 30, 2025, 10:05 PM UTC

cosmosgenius wrote: post #41

dakiol wrote: post #18

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…

one thing which causes problem with git for me is collaborative work without using "git server". This usually comes up at homelab situation with no access a "git server" or ssh server. One thing with jj is i can use existing sharing mechanism like dropbox, google drive or if nothing else just copying jj folder (granted all of those are bad idea w.r.t vcs but still).

Post by gpm » Thu, Oct 30, 2025, 10:09 PM UTC

verdverm wrote: post #61

gpm wrote: post #51

Earlier quoted context omitted.

Not 100% sure I understand what you're saying, but I think the answer is "yes". You can modify any* commit in `jj` regardless of whether it has commits on top of it at any time. Either by another commit into it, or by directly checking out the commit and editing the source tree. If this creates conflicts with commits on top of it `jj` just records those commits as having conflicts/adds conflict markers without interr…

So if I push a commit update, and then someone else pushes a commit to one I build on, and there is a conflict... How does recording the conflict, but not introducing it (if I'm understanding correctly), ... how does this affect my build/ci workflow?