Abstract:

This transcript captures a technical discussion among developers about designing and implementing a "tagging" feature for the jj version control system. The central challenge discussed is how to reconcile the concept of a permanent, immutable tag (akin to a software release version) with jj's core feature of a mutable history, where commits can be easily modified.

The group identifies three distinct use cases for naming commits: immutable tags for releases (like git tag), mutable names that follow a change as it's modified (jj bookmarks), and names for an active line of work (like git branch). The conversation explores the implications of mutating a tagged commit, which would create divergence, and debates whether this divergence should be made visible to the user or if the tagged commit should become truly immutable. The developers also compare jj's potential implementation with Git's two types of tags—lightweight (a simple reference) and annotated (a data object with metadata). The discussion concludes by leaning towards a pragmatic, jj-native solution: creating a concept of "immutable bookmarks" that would lock a change from further modification, satisfying the primary use case of creating release tags for platforms like GitHub.

Designing a Tagging Feature for the JJ Version Control System

• 0:00:37 - Defining "Tagging" in JJ: The initial proposal defines a tag as a name for a specific commit that is not intended to be updated. This is explicitly contrasted with jj's existing "bookmarks," which are designed to follow a change as it is amended or rebased.
• 0:03:52 - Three Core Use Cases for Naming: A speaker frames the problem by identifying three distinct user intentions for naming things in a version control system:
  1. Immutable Release Tags: A permanent name for a specific commit, like v1.0, that should never change.
  2. Mutable Change Bookmarks: A name that follows a specific line of work (a "change") even as its underlying commit is modified.
  3. Active Work Branches: A name for a location of work that automatically advances as new commits are added.
• 0:05:42 - The Mutability Dilemma: The core technical challenge is what should happen when a user modifies a commit that has been tagged. This action creates a divergent history, and the group debates how jj should handle and represent this state to the user.
• 0:10:36 - Visibility of Tagged Commits: When a tagged commit is modified, should the original tagged version remain visible in the log (creating a visible divergence) or be hidden? The consensus leans towards making the divergence visible, as modifying a tagged commit is a significant and potentially unexpected event for the user.
• 0:12:21 - Comparison with Git Tags: The discussion delves into the two main types of tags in Git: lightweight tags (simple file-based references to a commit hash) and annotated tags (richer data objects in the repository that can store metadata, such as a GPG signature).
• 0:18:21 - Key Proposal: "Immutable Bookmarks": A consensus begins to form around creating a jj-native feature called "immutable bookmarks." Applying such a tag would make the associated change and its commit truly immutable, preventing further modification and thus avoiding the divergence problem altogether.
• 0:25:00 - Design Philosophy: Native Solution vs. Git Replication: The developers debate whether the goal should be to perfectly replicate Git's tagging functionality or to create a simpler, native jj solution that addresses the most common user needs while still being compatible with Git. The group favors the native solution.
• 0:26:13 - The Primary Motivation: GitHub Releases: A key driver for this feature is the practical need for the jj project itself to create release tags. Currently, this must be done through the GitHub web UI, highlighting a clear gap in jj's command-line functionality. An "immutable bookmark" feature would directly solve this problem.