I actually was able to take notes for all the talks this time! Hope they're useful :D

Tomas Reimers: The History of Code Review

• Collaboration was always the hard part of building software

• Fagan Inspections -> earliest recorded code review

  • Printed out on paper (!! Emily's print to Remarkable review method)
• Email patches (Linux kernel still does this)
• Mondrian -> what if code review was actually meant for code review

• Cambrian explosion of online code review tools

  • Review Board, Gerrit/Critique, Phabricator, GitHub, etc
  • You are here
• A third of all pull requests now include automated contribution

• Why do we do code review?

  • Straightforward: validation -> is the code bad
  • Change management -> set ourselves up for pleasant failure
  • Alignment -> Get the ideas into more brains, reduce bus factor

• AI have theoretically solved validation, but not change management nor alignment

  • AI tends to bandaid validation vs. categorically eliminating the possibility of badness
• We now have to correctly manage orders of magnitude more changes than pre-AI and alignment is harder than ever because human brains can only absorb change to domain models so fast without massaging the brains and the data
• We humans are now the bottleneck in code review, meaning it is no longer a technical problem but a sociological problem

• Takeaway: The AI must talk to the forge directly

  • Humans as message passers are inefficient
  • Spec to diff as fast as possible (is this the way to go? Not sure)
  • Cultivation vs. iteration
• Takeaway: We need a way to know the priority of PRs ahead of time and get context for their key decisions

• Takeaway: Reviewing outputs will become as important as reviewing code

  • Is code the right thing to review? Or is the output of the code what we should care about
• How does today's continuing evolution in code review affect new programmers? Is this accessible? Or does this require foreknowledge that is becoming scarce?
• Stop forgetting to encode your business logic in types!
• Ephemeral environments and simulation is super important (I knew this tbh)
• AI has made developer onboarding a 1-2 digit per year problem to a 1-2 digit per day problem

• Can Jev computer use?

  • Jev -> https://typesafe.ai/blog/introducing-system-one-models-and-jev
• Automated vulnerability scanning and fixes (!!) is powerful and cognitively free
• See also: https://cursor.com/blog/git-at-any-scale

Brian M. Carlson: Rust in Git

• We want Rust in Git because it's a good language with lots of technical benefits (like a sensible standard library) and keeping Git as C only will unnecessarily repel some potential contributors who may have brought good brains to the project

  • Git's C impl has some globals that prevent things like being able to work with more than one repo at a time, less flexible
• What does "Lifetime of releases is 6 weeks" actually mean?

• This is probably more interesting for folks who haven't worked with Rust a ton yet, hopefully this helps sell it

  • It's great to hear that "Rust for Git" was basically unilaterally supported vs. "Rust for Linux Kernel" which was apparently treated as an evil virus of Satan for some reason
• Could Git and Jujutsu share primitives not just in spec but in code as well?

Scott Chacon: Git Meta

• Git Meta -> metadata for Git!

  • Information about your code that is not your code
• Granularity -> attach metadata to branches, paths, change IDs, projects
• Performance -> Git Notes is slow, this is fast
• Exchange -> Git as transport, don't sidechannel

• CRDTs strike again!!

  • But not really, just eventual consistency

• What are the use cases?

  • Trust and provenance
  • Review comments/artifacts (forge agnostic would be amazing)
  • Versions (evolog, history, lineage)
  • Licensing
  • Testing (this is the big one for me)
  • Binary files

• What do we have at present? Why aren't they enough?

  • Commit messages/trailers -> simple, but dumb and hard to interact with as data, can't mutate without changing the commit hash
  • Commit headers -> Similar problems, doesn't get copied on git rebase (only replay)
  • CODEOWNERS -> just another file, not great
  • Git Notes -> Awkward to utilize, doesn't scale well, mutation is weird
• Git Meta is a spec we can utilize to all read and write metadata the same way

• Definitely feels like the way to go for Jujutsu metadata personally

  • Design doc: design: Add support for per-revision metadata jj-vcs/jj#8166

• How do multiple actors communicate?

  • Local must be up to date with server before pushing new updates

• How does Git Meta scale?

  • Pruning
  • Blobless clones -> hydrate to populate most recent values
  • Shallow clones -> no hydration without deepening
  • Feels like we will need to be smart about how we approach all of this for JJ's implementation, our usage may not reflect Git's usage. Not sure as I haven't dug very deep into the code
• Very nice use case -> PR blame instead of commit blame
• Slides*: https://github.com/schacon/meta-park

• How does Git Meta play with Tangled's COBs?

  • See: Tangled: Knot-stored COB proposal by @boltless.me
  • Could be materialized as Git Meta data on pull, would require some kind of write control IMO
• We love abusing Git trees

Elijah Newren: Scaling Git for the AI Era

• The scale of PRs merged, commits pushed, and repos created is increasing exponentially

• Coloring algorithms to find merge bases

  • Inefficiency -> naive coloring algorithms don't stop when they can't ascertain any more information from the graph
  • Fix this -> up to 20-70x faster (!!)
  • Doesn't work on corrupt commit graphs (how do you get corrupt commit graphs?)

• Repacking

  • Fewer, bigger packs are more efficient for binary searches
  • Loose objects have the same problem
  • Repacking consolidates existing packs into more efficient ones
  • Keep up with new pushes by aggregating batches of pushes into new repacks

  • Repacking is expensive

    • Geometric repack -> 20-30 minutes
    • What if we only repack small packs? The large ones are already efficient
• How do you test Git performance at scale? Random generation? You don't exactly need the file contents to make any sense

• Partial clones

  • Basically just don't hydrate files until later
  • Naive hydration just gets one file at a time instead of batching them
  • git backfill -p <range> can help with this

• Shallow clones

  • Basically just don't fetch all of history, orthogonal to partial
  • A shallow clone may be mistaken for completely unpushed history

Christian Schilling: Josh: Beyond Subtrees

• Josh -> Monorepos w/ selectively shared code

  • Mono vs poly is universal
• Subtrees just weren't enough for Rust's monorepo

• Josh utilizes "filter algebras" to directly run maps on the DAG and create a self-contained history that's unrelated to the working tree

  • Revsets for code

• Git-native, distributable materialized views

  • Keep up, Postgres
• Can filter on a number of ways to project the repo into a manageable view

• Very very highly performant

  • Only possible by taking full advantage of Git's mechanisms and is thus very tightly coupled
  • Basically instead of abstracting away what Git does it actually throws out a good amount of Git's native abstractions to get closer to the data
  • Does this work with JJ? What about our plans for metadata?

• Note to self: Check this shit out it looks cool

  • https://josh-project.dev/
  • https://blog.rust-lang.org/inside-rust/2026/06/04/how-josh-helps-rust-manage-code-across-multiple-repositories/

Raphaël Gomès & Pierre-Yves David: Checking out another branch of Version Control

• How does Mercurial differ from Git?

• CRDTs strike again!!!!!

  • Orderless eventual resolution of concurrent writes
• Git branches do NOT behave like CRDTs

• Mercurial branches seem remarkably similar to JJ branches in experience

  • Basically what I'm getting out of this is Git branches have always been bad
• Does JJ contain non-CRDT primitives?
• Tbh a lot of this seems almost uncomfortably similar to how Jujutsu operates locally. Mercurial appears to have the advantage of having Mercurial-native remotes which means all parties can share this mutable history, while currently Jujutsu is restricted to what Git remotes and forges can accept and compute/extrapolate
• Commits that never reach the main server never bottleneck the main server

Patrick Steinhardt: Rebuilding Git

• GitLab is building a new storage foundation for Git
• Git was designed for a different world where DVCS was actually used in a decentralized manner, whereas today it simply is by and large not

• This problem is exponentially exacerbated by agentic development

  • I have thoughts and concerns about how this seems to be outpacing what I think is a pace enabled by agentic workflows targeted at quality and rigor, but that's not for today
• If Mercurial is pitching that this could be avoided by actually working in a decentralized manner, but Git is only used in a centralized manner, how do you resolve this conflict?
• Pitch is basically "what if we replaced reftables with something more scalable"
• Okay tbh I don't know what notes to take on this but the demos are cool as shit, you should watch the VOD
• "what if we put reftables and packfiles in S3?"
• I clearly have a lot to learn about Git internals

Anirudh Oppiliappan: The Git Forge Must Be Hackable

• The emacsification of software
• I will probably have the fewest notes on this talk as I am super engaged with Tangled already
• sh.tangled.*, not org.tangled.* (unless I missed something or it's set per user)

• Collaborative objects:

  • Required because repository data is not single-user
  • Tangled: Knot-stored COB proposal by @boltless.me
• Bobbin: https://blog.tangled.org/bobbin/

• Everything is XRPC lololol

  • If it looks like a knot and walks like a knot and quacks like a knot it's a knot
  • Same with spindles
• Once again the demo is super cool and you should watch the VOD
• New profile view looks pretty hype actually
• New PR view looks actually maybe like it addresses my one-commit-per-logical-PR complaints
• Tangled seems to me to be one of the leanest, must chunkable forges I have ever seen and I can't see myself using anything else even if Tangled itself dies

Toon Claes: Git Smartlog

• Can we make a smartlog for Git?
• JJ has a customizable log template you can use to implement basically whatever you want

• Can we make the smartlog less wide?

  • First parent removes too much relevant data
  • Graph line limit is naive
• Only show "my" changes?
• Again probably worth watching the VOD but this feels largely like something JJ's implementation does very well with log templates and revsets
• This is a lot of --flags that could probably be config values

• Decorations are cool, JJ doesn't have that. Is that cached?

  • If not then that's a lot of network calls per graph and I personally call jj log all the time
• I would argue that JJ doesn't force an opinion on anyone with its log, it ships a sensible default and is highly customizable through templates and revsets
• renderdag in Git would be sick
• We should entice users into our software and encourage them to use cool parts of it

Emily Shaffer: SHA-256 at a Hyperscaler

• Hash functions enable confidence in authenticity
• Collisions are scary because SHA-1 is broken and GPUs are ever more present
• SHA-256 is not broken and is way stronger

• How do we switch?

  • Anything that was SHA-1 is still SHA-1, including objects we might naively reuse
  • We can't really just do a cutoff
  • SHA-1 anywhere means the whole tree is susceptible
• It's all about identity baybee
• Git therefore forbids mixing SHA-1 and SHA-256, which means a verified good copy of the repo has to be reconstructed from scratch... except commit hashes are used as a global identity everywhere

• How do we secure the True Name of a commit without revoking the True Name of a commit?

  • The answer is with a lot of pain apparently