Proto commits in jj-vcs/jj

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-05-25

op_store: add per-workspace git_head tracking

2026-05-06

git: move remote head to view object Previously, the revset-alias trunk was set to the HEAD of some remote. (Usually the first one - on clone or init.) This was done by writing to a repo-specific config file. This prevented the default trunk alias from behaving better in the presence of multiple remotes. Users were also unable to customize the trunk alias on a global level, since it was always overwritten at the repo level. Fix this by moving the information of a remote's HEAD to the view object. The new `remote_heads()` revset function can be used to extract this information. The default trunk alias is changed to consider all bookmarks matching the HEAD of any remote or some common conventions as "independent" trunks. This ensures that even if there are multiple remotes with diverging and differently-named default bookmarks, all revisions reachable from them are still considered immutable by default. This also fixes the issue where Jujutsu unnecessarily writes to XDG_CONFIG_HOME. This is often annoying and sometimes impossible.

2026-04-15

config: Implement managed config design doc This follows decisions made in docs/design/managed-config.md.

2026-04-07

templater: deprecate `Operation.tags()` in favor of `.attributes()` As we have discussed in at least https://github.com/jj-vcs/jj/pull/8148, the name `.tags()` is not a good name because it can be assumed to be related to the usual kind of VCS tags.

2026-04-01

config: Implement managed config design doc This follows decisions made in docs/design/managed-config.md.

2026-03-24

op_store: record workspace where operation was run There are two reasons for this: * It helps understanding why divergence happened to see which workspace an operation was run from. For example, perhaps an agent is running in another workspace and it's not obvious from the operation log which commands it ran without seeing the workspace name. * We may want to check that e.g. `jj undo` is run from the same workspace as the operation it's undoing. We may want to print a warning otherwise, or maybe we want to skip over operations create from other workspaces. I'm not sure what's best but having the workspace recorded at least enables such features.

2026-01-21

workspaces: Allow retrieving the path of another workspace This allows `jj workspace root` command to take an optional workspace arg to print the root directory of that workspace, while defaulting to the current workspace. We allow this by creating a new `workspace_store` which has a separate entry for each workspace containing its name and root directory. This store is created during initiation of the repo and is maintained whenever `add`, `forget` & `rename` workspace subcommands are executed. CAUTION: Moving a workspace path will not sync the path stored in the workspace store. CAUTION: Specifying `jj workspace root` with a workspace created before this will result in an error.

2026-01-12

config: Implement secure-config design doc. See docs/design/secure-config.md for many more details. Fixes #3303 Fixes #1595

2025-12-09

protos: add conflict labels to working copy and simple backend

2025-11-02

protos: add conflict labels to working copy and simple backend

2025-10-31

protos: add conflict labels to working copy and simple backend

2025-10-28

protos: add conflict labels to working copy and simple backend

2025-10-26

protos: add conflict labels to working copy and simple backend

2025-10-25

protos: add conflict labels to working copy and simple backend

2025-10-23

protos: add conflict labels to working copy and simple backend

2025-10-22

protos: add conflict labels to working copy and simple backend

2025-10-20

protos: add conflict labels to working copy and simple backend

2025-10-19

protos: add conflict labels to working copy and simple backend

2025-10-18

protos: add conflict labels to working copy and simple backend

2025-10-16

protos: add conflict labels to working copy and simple backend

protos: add conflict labels to working copy and simple backend

2025-10-14

protos: add conflict labels to working copy and simple backend

2025-10-11

protos: add conflict labels to working copy and simple backend

2025-10-10

protos: add conflict labels to working copy and simple backend

2025-09-30

op_store: rename tags field to local_tags I'm going to rename "tag" in the view API to "local_tag". Since the underlying data structures are split to View and RemoteView, it's not important to add "local_" prefix. However, I think this change is good for consistency.

The documentation is generated from this commit.

2025-09-24

op_store: add remote tags storage and basic accessors Git-tracking tags will be stored there. I don't have a concrete plan for proper remote tags support, but I think tags fetched/pushed internally can be recorded as remote tags.

git, op_store: migrate and import "refs/tags/*" as @git remote tags The migration logic is basically the same as 717d0d3d6d "git: on deserialize/import/export, copy refs/heads/* to remote named git." Now git::import_refs() processes bookmarks and tags in the same way. git::export_refs() is unchanged because we don't have any commands that would move local tags internally.

op_store: reorganize proto reflecting new RemoteView structure I'm thinking of adding remote tags table to support tag mutation commands, so I think it's time to update the storage format. RefTarget is serialized to a list of alternate terms because we don't need to support legacy formats here.

2025-09-23

op_store: add remote tags storage and basic accessors Git-tracking tags will be stored there. I don't have a concrete plan for proper remote tags support, but I think tags fetched/pushed internally can be recorded as remote tags.

git, op_store: migrate and import "refs/tags/*" as @git remote tags The migration logic is basically the same as 717d0d3d6d "git: on deserialize/import/export, copy refs/heads/* to remote named git." Now git::import_refs() processes bookmarks and tags in the same way. git::export_refs() is unchanged because we don't have any commands that would move local tags internally.

op_store: reorganize proto reflecting new RemoteView structure I'm thinking of adding remote tags table to support tag mutation commands, so I think it's time to update the storage format. RefTarget is serialized to a list of alternate terms because we don't need to support legacy formats here.

2025-09-22

op_store: remove stale TODO about renamed remote and view state We aren't going to fix this problem by inserting another indirection, at least to the view layer.

2025-09-21

op_store: remove stale TODO about renamed remote and view state We aren't going to fix this problem by inserting another indirection, at least to the view layer.

2025-09-20

git, op_store: migrate and import "refs/tags/*" as @git remote tags The migration logic is basically the same as 717d0d3d6d "git: on deserialize/import/export, copy refs/heads/* to remote named git." Now git::import_refs() processes bookmarks and tags in the same way. git::export_refs() is unchanged because we don't have any commands that would move local tags internally.

op_store: add remote tags storage and basic accessors Git-tracking tags will be stored there. I don't have a concrete plan for proper remote tags support, but I think tags fetched/pushed internally can be recorded as remote tags.

op_store: reorganize proto reflecting new RemoteView structure I'm thinking of adding remote tags table to support tag mutation commands, so I think it's time to update the storage format. RefTarget is serialized to a list of alternate terms because we don't need to support legacy formats here.

2025-09-19

op_store: flag legacy git_refs.commit_id field as deprecated

2025-09-18

op_store: flag legacy git_refs.commit_id field as deprecated

2025-09-04

simple_store: drop support for legacy trees Users should not be using the simple backend for anything serious, and they definitely should not have any repos from back when we used legacy trees.

working_copy: drop support for legacy trees Legacy trees (those with conflicts recorded at the path level) have not been created since 0.11 (Nov 2023). We're about to deprecate them now. This patch removes support for them in the working copy. If anyone still has a commit checked out at a legacy tree, we will now interpret that as a modern tree, meaning that any conflicts will appear as regular files with JSON contents in the previous snapshot, so if we re-snapshot the working copy (and e.g. the mtime has changed), these files will become resolved with the conflicts markers still in them. I think it's quite unlikely that anyone has working copies this old so I didn't mention it in the changelog.

backend: remove unused TreeValue::Conflict and read/write methods We no longer use the `TreeValue::Conflict` constructor or the `Backend::read_conflict()` and `Backend::write_conflict()` methods.

backend: remove unused TreeValue::Conflict and read/write methods We no longer use the `TreeValue::Conflict` constructor or the `Backend::read_conflict()` and `Backend::write_conflict()` methods.

simple_store: drop support for legacy trees Users should not be using the simple backend for anything serious, and they definitely should not have any repos from back when we used legacy trees.

working_copy: drop support for legacy trees Legacy trees (those with conflicts recorded at the path level) have not been created since 0.11 (Nov 2023). We're about to deprecate them now. This patch removes support for them in the working copy. If anyone still has a commit checked out at a legacy tree, we will now interpret that as a modern tree, meaning that any conflicts will appear as regular files with JSON contents in the previous snapshot, so if we re-snapshot the working copy (and e.g. the mtime has changed), these files will become resolved with the conflicts markers still in them. I think it's quite unlikely that anyone has working copies this old so I didn't mention it in the changelog.

2025-09-03

working_copy: calculate and store content hash of materialized conflicts This will help detect unchanged conflict files.

working_copy: mark unused `conflict_id` proto field reserved The field has been unused since it was deprecated in 97b81a0f (~2 years ago). It should have been marked reserved instead of deprecated already then.

2025-09-02

working_copy: calculate and store content hash of materialized conflicts This will help detect unchanged conflict files.

2025-08-14

protos: rename `working_copy` to `local_working_copy` The `working_copy` proto is specific to `LocalWorkingCopy`, so I think it should match that name.

protos: rename `op_store` to `simple_op_store` Similar to the previous commit, `op_store` is specific to `SimpleOpStore`, so its name should match that.

2025-08-13

working_copy: mark unused `conflict_id` proto field reserved The field has been unused since it was deprecated in 97b81a0f (~2 years ago). It should have been marked reserved instead of deprecated already then.

2025-08-11

index: migrate operation link file to protobuf I'm going to add changed-path index, and the operation link file will store a list of segment files and a starting commit position. Suppose the link file is small, we wouldn't need our own serialization format. This patch adds new directory for proto-based operation link files. We could reuse the existing directory, but that would make debugging a bit harder.

index: read/write changed-path index segments

2025-08-07

index: migrate operation link file to protobuf I'm going to add changed-path index, and the operation link file will store a list of segment files and a starting commit position. Suppose the link file is small, we wouldn't need our own serialization format. This patch adds new directory for proto-based operation link files. We could reuse the existing directory, but that would make debugging a bit harder.

index: read/write changed-path index segments

2025-06-03

backend: add CopyId to TreeValue::File This patch adds a `TreeValue::File::copy_id` field. The copy ids are always empty for now. I preserved the copy id where it was easy to do so, plus in a few non-trivial cases. In other places, however, I made the code use a new copy id. I added a `CopyId::placeholder()` function for creating a new copy id where we need one. We should eventually fix all callers to either preserve an existing copy or to generate a new one.

2025-05-29

backend: add CopyId to TreeValue::File This patch adds a `TreeValue::File::copy_id` field. The copy ids are always empty for now. I preserved the copy id where it was easy to do so, plus in a few non-trivial cases. In other places, however, I made the code use a new copy id. I added a `CopyId::placeholder()` function for creating a new copy id where we need one. We should eventually fix all callers to either preserve an existing copy or to generate a new one.

backend: add CopyId to TreeValue::File This patch adds a `TreeValue::File::copy_id` field. The copy ids are always empty for now. I preserved the copy id where it was easy to do so, plus in a few non-trivial cases. In other places, however, I made the code use a new copy id. I added a `CopyId::placeholder()` function for creating a new copy id where we need one. We should eventually fix all callers to either preserve an existing copy or to generate a new one.

2025-05-27

backend: add CopyId to TreeValue::File This patch adds a `TreeValue::File::copy_id` field. The copy ids are always empty for now. I preserved the copy id where it was easy to do so, plus in a few non-trivial cases. In other places, however, I made the code use a new copy id. I added a `CopyId::placeholder()` function for creating a new copy id where we need one. We should eventually fix all callers to either preserve an existing copy or to generate a new one.

2025-05-26

op_store: load/store commit predecessors Operation ids in test_op_abandon*() are changed because reparented operations now preserve the predecessors mapping. Since this patch will affect whether "jj evolog" can show the associated operations, I added a changelog entry. It's still a bit vague, but I think we can add a more detailed explanation later.

2025-03-31

view: rename workspace "id" to "name" This matches the current implementation.

view: rename RemoteRefState::Tracking to Tracked In jj's model, a local bookmark "tracks" remote bookmarks. It's wrong to call a remote bookmark state as "tracking".

2025-03-19

protos: finish local_store->simple_store migration from f8ab8a0e

2025-03-17

lib: rename the LocalBackend to SimpleBackend This makes it clear to source code readers, that it isn't the _native backend_ the project talks about in the Roadmap.

2025-03-12

backend: add CopyId to TreeValue::File I think it's still undecided if we want to also have a `CopyId ` in `TreeValue::Symlink`.

2025-01-08

lib: remove hack to migrate old git remotes Deletes another vestigial trace of git in the lib crate. Signed-off-by: Austin Seipp <aseipp@pobox.com>

2024-12-21

local_working_copy: store materialized conflict marker length Storing the conflict marker length in the working copy makes conflict parsing more consistent, and it allows us to parse valid conflict hunks even if the user left some invalid conflict markers in the file while resolving the conflicts.

2024-10-13

view: deprecate git_head, introduce git_heads (a HEAD per workspace) Previously, JJ's view of the git head (HEAD@git) could only track one HEAD, for only one workspace, specifically the one colocated with the main .jj/repo. Since we now allow workspaces to be colocated, we need to track a separate git HEAD per workspace. This allows us to import HEAD for only the current workspace, and export HEAD to the current workspace when @- moves. Thereby allowing git tools to behave correctly in those workspaces. This affects a lot of stuff. And a lot of tests. A lot more things need to know the current workspace ID, including e.g. the revset resolvers, and the commit templater.

2024-09-12

bookmarks: rename proto symbols from "branch" Proto fields are identified by the tag (and the message names are not used), so it's safe to rename them.

2024-05-31

working_copy: Add `is_file_states_sorted` to tree state proto See #2651 and a935a4f70c9c4c4a76009f9aee3bdaa1f7b9084e for more background. This speeds up `jj log` in a large repo with watchman enabled by around 9%: ``` $ hyperfine --sort command --warmup 3 --runs 20 -L bin \ jj-before,jj-after "target/release/{bin} -R ~/chromiumjj/src log" Benchmark 1: target/release/jj-before -R ~/chromiumjj/src log Time (mean ± σ): 788.3 ms ± 3.4 ms [User: 618.6 ms, System: 168.8 ms] Range (min … max): 783.1 ms … 793.3 ms 20 runs Benchmark 2: target/release/jj-after -R ~/chromiumjj/src log Time (mean ± σ): 713.4 ms ± 5.2 ms [User: 536.1 ms, System: 176.2 ms] Range (min … max): 706.6 ms … 724.7 ms 20 runs Relative speed comparison 1.11 ± 0.01 target/release/jj-before -R ~/chromiumjj/src log 1.00 target/release/jj-after -R ~/chromiumjj/src log ```

2024-05-04

lib: add topic metadata to view

2024-04-17

bluesky: copy tracing API

2024-02-20

op_store: add metadata flag for ops representing working-copy snapshot It should be useful at least in the presentation layer to know which operations correspond to working-copy snapshots. They might be rendered differently in the graph, for example. Or maybe an undo command wants to warn if you just undid a snapshot operation. This patch just introduces a field in the metadata to store the information.

2024-01-14

view: drop tracking of public heads We've had the public_heads for as long as we've had the View object, IIRC (I didn't check), but we still don't use it for anything. I don't have any concrete plans for using it either. Maybe our config for immutable commits is good enough, or maybe we'll want something more generic (like Mercurial's phases). For now, I think we should simplify by removing it the storage for public heads.

2024-01-13

working_copy: mark commit_id field in proto reserved By marking it reserved, we prevent accidental use. We can still read working copy protos that have the field.

2023-11-19

working_copy: don't build intermediate HashMap from proto file states According to the doc, this is compatible with the map syntax. https://protobuf.dev/programming-guides/proto3/#maps This change means that the serialized file states are sorted by RepoPath, so BTreeMap<RepoPath, _> can be reconstructed with fewer cache misses. In my "linux" repo (watchman enabled): - jj-0: baseline - jj-1: this % hyperfine --sort command --warmup 3 --runs 10 -L bin jj-0,jj-1,jj-2 \ "target/release-with-debug/{bin} -R ~/mirrors/linux status" Benchmark 1: target/release-with-debug/jj-0 -R ~/mirrors/linux status Time (mean ± σ): 1.034 s ± 0.020 s [User: 0.881 s, System: 0.212 s] Range (min … max): 1.011 s … 1.068 s 10 runs Benchmark 2: target/release-with-debug/jj-1 -R ~/mirrors/linux status Time (mean ± σ): 849.3 ms ± 13.8 ms [User: 710.7 ms, System: 199.3 ms] Range (min … max): 821.7 ms … 870.2 ms 10 runs Relative speed comparison 1.32 ± 0.04 target/release-with-debug/jj-0 -R ~/mirrors/linux status 1.08 ± 0.03 target/release-with-debug/jj-1 -R ~/mirrors/linux status Cache-misses got reduced: % perf stat -e task-clock,cycles,instructions,cache-references,cache-misses \ -- ./target/release-with-debug/jj-0 -R ~/mirrors/linux --no-pager status 1,091.68 msec task-clock # 1.032 CPUs utilized 4,179,596,978 cycles # 3.829 GHz 6,166,231,489 instructions # 1.48 insn per cycle 134,032,047 cache-references # 122.776 M/sec 29,322,707 cache-misses # 21.88% of all cache refs 1.057474164 seconds time elapsed 0.897042000 seconds user 0.194819000 seconds sys % perf stat -e task-clock,cycles,instructions,cache-references,cache-misses \ -- ./target/release-with-debug/jj-1 -R ~/mirrors/linux --no-pager status 927.05 msec task-clock # 1.083 CPUs utilized 3,451,299,198 cycles # 3.723 GHz 6,222,418,272 instructions # 1.80 insn per cycle 98,499,363 cache-references # 106.251 M/sec 11,998,523 cache-misses # 12.18% of all cache refs 0.855938336 seconds time elapsed 0.720568000 seconds user 0.207924000 seconds sys

2023-11-12

sign: Implement storage for digital commit signatures Recognize signature metadata from git commit objects, implement a basic version of that for the native backend. Extract the signed data (a commit binary repr without the signature) to be verified later.

2023-10-16

op_store: minimal change to load/store tracking state of remote branches We could instead migrate the storage types to (local_branches, remote_views), but that would be more involved and break forward compatibility with little benefit. Maybe we can do that later when we introduce remote tags.

2023-10-07

git: on deserialize/import/export, copy refs/heads/* to remote named "git" I've added a boolean flag to the store to ensure that the migration never runs more than once after the view gets "op restore"-d. I'll probably reorganize the branches structure to support non-tracking branches later, but updating the storage format in a single commit would be too involved. If jj is downgraded, these "git" remote refs would be exported to the Git repo. Users might have to remove them manually.

2023-08-27

working_copy: enable storing multiple tree ids in state file

2023-08-26

local_backend: allow storing legacy trees Unlike the git backend, we don't need to support path-level conflicts for existing repos because we don't care about compatibility with existing repos using the native backend. However, we still need to support both formats until all code paths are able to handle tree-level conflicts.

git_backend: remove unused proto field for resolved tree id We store resolved tree ids in the regular Git commit, so we we never ended up using the `resolved` variant in the `root_tree`.

backends: store tree id conflicts as list with alternating signs Now that we have `Merge::iter()` and friends, it's simpler to store the tree ids in a single list.

2023-07-27

simple_op_store: add deserialization support of new Conflict-based RefTarget CommitId is wrapped with a message since we need a representation for None. This is different from TreeConflict in which an empty tree has an id.

2023-07-24

working_copy: don't track conflict-ness in state file, use tree object The working copy's current tree tracks whether a file is a conflict. We also track that in the `TreeState` object. That allows us to not read the trees object to decide if we should try to parse a file as a conflict. One disadvantage is that it's redundant information that needs to be kept in sync with the tree object. Also, for Watchman, we would like to completely ignore the persisted `FileState`. This commit removes the `FileType::Conflict` variant and instead checks in the tree object whether a given path was a conflict. This is the change I mentioned in dc8a20773760. We still skip the check completely if the file's mtime etc. is unchanged, so it shouldn't have much effect in the common case of a mostly unchanged working copy. I measured a slowdown on `jj diff` by ~3% in the Linux repo with a clean working copy with all mtimes bumped. I think the simpler code and reduced risk of subtle bugs is worth the performance hit.

2023-07-20

backend: learn to store tree-level conflicts Tree-level conflicts (#1624) will be stored as multiple trees associated with a single commit. This patch adds support for that in `backend::Commit` and in the backends. When the Git backend writes a tree conflict, it creates a special root tree for the commit. That tree has only the individual trees from the conflict as subtrees. That way we prevent the trees from getting GC'd. We also write the tree ids to the extra metadata table (i.e. outside of the Git repo) so we don't need to load the tree object to determine if there are conflicts. I also added new flag to `backend::Commit` indicating whether the commit is a new-style commit (with support for tree-level conflicts). That will help with the migration. We will remove it once we no longer care about old repos. When the flag is set, we know that a commit with a single tree cannot have conflicts. When the flag is not set, it's an old-style commit where we have to walk the whole tree to find conflicts.

2023-07-08

feat(fsmonitor): Watchman filesystem monitor implementation

2023-06-22

backend: drop deprecated fields from `local_store.proto` We don't even try to preserve compatibility with old repos using the local backend.

backend: split up `store.proto` in git and local versions It was convenient that what the git backend stored in its "extras" table is exactly a subset of the fields that local backend stores, but it's bit ugly and limiting. For example, it makes it possible to populate the `author` field in the git extras, but that would have no effect. It's better that it's not possible to do that (we store the author field in the git commit, of course). What made me notice this now was that I'm working on tree-level conflicts (#1624) and I'm thinking of adding a field to the git extras saying "this commit has single tree, but it's still a new-style commit", so we can know not to walking such trees to find path-level conflicts. That's only needed for the git backend because we don't care about compatibility for the local backend.

2023-05-31

working_copy: get conflict id from the current tree This prepares for allowing the base tree to be a conflict at the root-tree level (#1624). We could remove the `Conflict` variant completely. I tried doing that and it slowed down `jj diff` by ~3% in the Linux repo with a clean working copy with only mtime bumped on all files.

2023-05-18

test proto change

2023-02-18

backend: rename `ConflictPart` to `ConflictTerm` It took a while before I realized that conflicts could be modeled as simple algebraic expressions with positive and negative terms (they were modeled as recursive 3-way conflicts initially). We've been thinking of them that way for a while now, so let's make the `ConflictPart` name match that model.

2023-01-30

git: allow conflicts in "HEAD@git" Git's HEAD ref is similar to other refs and can logically have conflicts just like the other refs in `git_refs`. As with the other refs, it can happen if you run concurrent commands importing two different updates from Git. So let's treat `git_head` the same as `git_refs` by making it an `Option<RefTarget>`.

2023-01-25

cleanup: update more "checkout" to "working-copy commit" and similar I've preferred "working-copy commit" over "checkout" for a while because I think it's clearer, but there were lots of places still using "checkout". I've left "checkout" in places where it refers to the action of updating the working copy or the working-copy commit.

2022-12-01

git: do not delete or track git submodules. A new FileType, GitSubmodule is added which is ignored. Files or directories having this type are not added to the work queue and are ignored in snapshot. Submodules are not created by jujutsu when resetting or checking out a tree, they should be currently managed using git.

2022-11-28

copyright: change from "Google LLC" to "The Jujutsu Authors" Let's acknowledge everyone's contributions by replacing "Google LLC" in the copyright header by "The Jujutsu Authors". If I understand correctly, it won't have any legal effect, but maybe it still helps reduce concerns from contributors (though I haven't heard any concerns). Google employees can read about Google's policy at go/releasing/contributions#copyright.

2022-11-15

backend: rename `NormalFile` to just `File` There are no "non-normal" files, so "normal" is not needed. We have symlinks and conflicts, but they are not files, so I think just "file" is unambiguous. I left `testutils::write_normal_file()` because there it's used to mean "not executable file" (there's also a `write_executable_file()`). I left `working_copy::FileType::Normal` since renaming `Normal` there to `File` would also suggest we should rename `FileType`, and I don't know what would be a better name for that type.

2022-11-05

backend: remove `Commit::is_open` field from data model

2022-09-30

backend: allow negative timestamps in commits and operations I was reading a draft of "Git Rev News: Edition 91" [1] where Peff mentions some unfinished patches to allow negative timestamps in Git. So I figured I should add support for that before I forget. I haven't checked if libgit2 supports it, so it might be that our Git backend still doesn't support it after this patch. [1] https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-91.md

2022-09-18

cleanup: rename `checkout` to `wc_commit` `wc_commit` seems clearer than `checkout` and not too much longer. I considered `working_copy` but it was less clear (could be the path to the working copy, or an instance of `WorkingCopy`). I also considered `working_copy_commit`, but that seems a bit too long.

2022-05-05

protos: move `.proto` files to more conventional `src/protos/`