This is a transcript of a technical discussion about a proposed "topics" feature for the Jujutsu (jj) version control system. The central challenge is the lack of a unified definition, with participants holding different mental models based on prior art from systems like Git, Gerrit, and Mercurial.
Key points of contention include whether a topic should be a topologically related series of commits (like a Git branch) or an arbitrary set of labeled commits (like a Gerrit topic), and whether a commit can belong to multiple topics. The discussion also explores implementation details, such as whether topics should be "infectious" (inherited by child commits) and if they should be a local-only organizational tool or a concept shared with remote servers for workflows like code review. A promising and flexible alternative emerges throughout the conversation: defining topics not as a new, rigid primitive, but as named "revsets" (saved queries), which could be shared via version-controlled configuration files. While no final decision is reached, the dialogue highlights the feature's inherent complexity and the difficulty in designing a single concept to meet diverse user expectations.
Defining 'Topics' in Version Control: A Deep Dive into a Complex Feature Proposal
00:00:08 The Core Problem: What is a "Topic"? The discussion begins by establishing the central issue: after one and a half years, there is still no community consensus on what a "topic" is or how it should behave, with different users expecting it to map to concepts like Git branches or Gerrit topics.
00:01:41 Conflicting Models from Prior Art: The group discusses different existing implementations. Gerrit's "topics" are cited as a key example, where a topic is a tag applied to a set of commits that may not be topologically related but are grouped for a purpose, such as a single code review. This contrasts with the idea of a topic being equivalent to a linear branch.
02:48 Gerrit's Strict "Topics" vs. "Hashtags": A distinction is made within the Gerrit model: "topics" are used for a strict set of changes that must be submitted together (often across repositories), while "hashtags" are more like simple labels for related but independent changes.
05:38 Primary Use Cases: The discussion identifies several desired use cases for topics:
Archiving an arbitrary set of commits under a single name.
Mapping a set of commits to a Git branch for a pull request.
Integrating with Gerrit's multi-commit review workflow.
10:17 Should Topics be "Infectious"? A key behavioral question is raised: should a new commit automatically inherit the topic(s) of its parent? While this could be useful for maintaining a "branch," it might not be desirable for all workflows.
11:09 A Flexible Alternative: Topics as Revsets: A powerful idea is proposed: instead of a new, rigid feature, topics could be implemented as named "revsets" (saved queries). This would allow for immense flexibility; for example, an "infectious" topic could be defined with a query like descendants(X), while a static topic could be a list of commit IDs.
17:48 Local vs. Remote Scope: A major point of debate is whether topics should be a local-only organizational tool or a feature that is shared with remote servers. Sharing topics would enable complex workflows like atomically landing a set of commits on a server.
23:37 Solving a Real-World Workflow: A participant from Google notes that topics could provide an ergonomic solution for their "multi-commit workflow," where developers want to group several commits into a single code review unit (CL), a model some users prefer over the one-commit-per-CL standard.
30:54 Reducing Scope to a "Submit Unit": To simplify the problem, it's suggested that the scope could be narrowed to a "submit unit"βa set of commits that must be submitted together. This would directly address the core Gerrit use case and make the feature less ambiguous.
33:40 The Future May Be Version-Controlled Revsets: The discussion concludes by circling back to the idea of using named revsets, especially when combined with the upcoming ability to have version-controlled repository configuration. This would allow users to define, share, and evolve their own "topics" without the system needing to enforce a single, rigid definition.