Abstract:

This transcript captures a discussion about enhancing automated code formatting within the Jujutsu (jj) version control system. The conversation begins by acknowledging the utility of existing tools like jj fix for applying formatters to commits but quickly identifies its primary limitation: its inability to provide project-level context required by many modern formatters (e.g., for Rust). The central proposal is a new jj run command that would materialize a working copy to provide this necessary context. The discussion then explores the significant performance challenges of this approach and brainstorms potential solutions, including caching, sparse materialization, and leveraging virtual or copy-on-write file systems (VFS, ZFS). Finally, the group explores a more advanced concept of a "presentation layer," where jj would apply user-specific formatting preferences on checkout while storing a canonical format in the repository, similar to Git's smudge/clean filters. This raises questions about user experience with commands like diff but also presents a potential solution for eliminating whitespace-related merge conflicts.

Improving Code Formatting in Jujutsu (jj)

• 0:00:03 - Motivation and Current State: The session's goal is to explore how the jj version control system can improve upon existing code formatting workflows. The current command, jj fix, applies formatters to committed code but operates on files in isolation.
• 0:03:25 - The Problem with Isolated Formatting: A key limitation of jj fix is that it cannot handle formatters that require project-wide context. For example, Rust's formatter needs to understand the entire "crate" to work correctly, which is impossible when processing single files via standard input/output.
• 0:05:13 - Proposal: jj run for Context-Aware Formatting: A conceptual jj run command is proposed as a solution. Unlike jj fix, this command would materialize a full working directory before running a formatter, providing the necessary context for complex tools.
• 0:06:37 - Configuration Difficulties: A pain point with the current system is its layered configuration. It's difficult to override global or repository-level formatter settings for a specific project without explicitly disabling the previously defined configurations.
• 0:10:43 - Success Story: Eliminating Merge Conflicts: A user shares a success story where running jj fix on a legacy repository instantly resolved 11 merge conflicts caused by inconsistent formatting. This works because jj fix rewrites commits directly without performing a rebase, thus avoiding merge operations.
• 0:14:27 - Solving Performance Challenges of jj run: The main hurdle for jj run is the performance cost of repeatedly materializing entire project trees. Potential solutions discussed include using a virtual file system (VFS), caching, or leveraging efficient copy-on-write filesystems like ZFS to create temporary workspaces.
• 0:19:11 - Advanced Concept: Formatting as a "Presentation Layer": The discussion explores a more radical idea where code is stored in a canonical format, but jj applies user-specific preferences (e.g., tabs vs. spaces) when checking out files. This would separate the stored "data layer" from the user-facing "presentation layer."
• 0:21:45 - User Experience Implications: This presentation layer approach would mean that commands like jj diff would operate on the underlying canonical data. A user could make a change that is purely stylistic (e.g., adding a space), and jj diff might report no changes, which could be confusing. The major benefit, however, would be the elimination of most whitespace-based merge conflicts.
• 0:26:08 - How Formatting Can Create Conflicts: The session concludes with a reminder that while formatting can solve conflicts, it can also introduce them. A minor change, like lengthening a variable name, can cause a formatter to re-indent an entire block of code, creating large-scale conflicts with other branches.