Proto commits in jj-vcs/jj

These 57 commits are when the Protocol Buffers files have changed:

2025-03-31

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

The documentation is generated from this commit.

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

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`.

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.

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/`

cargo: upgrade protobuf crates to 3.0.1 The biggest difference in the API is that fields are now public. The exception from that is `oneof` fields, which still require setters and getters. I couldn't measure any difference in performance. I didn't expect any difference either, but it's good that it didn't seem to regress. I timed `jj debug operation <some hash prefix>`, which will read the whole operation log (to check that the prefix is unambiguous).

2022-04-26

working_copy: record sparse patterns in the tree state (#52) This patch makes room for sparse patterns in the `TreeState` proto message. We also start setting that value to a list of just the pattern `.` when we create new working copies. Old working copies without the sparse patterns are also interpreted as having that single pattern. Note that this absence of sparse patterns is different from a present list of no patterns. The latter is a valid state and means that no paths are included in the sparse checkout.

2022-02-13

working_copy: stop keeping track of commit ID

2022-02-02

working_copy: keep track of workspace ID (#13) This patch makes it so the workspace ID can be stored in `.jj/working_copy/checkout`. The workspace ID is still always "default".

op_store: add support for tracking multiple workspaces (#13) This patch teaches the `View` object to keep track of the checkout in each workspace. It serializes that information into the `OpStore`. For compatibility with existing repos, the existing field for a single workspace's checkout is interpreted as being for the workspace called "default". This is just an early step towards support for multiple workspaces. Remaining things to do: * Record the workspace ID somewhere in `.jj/` (maybe in `.jj/working_copy/`) * Update existing code to use the workspace ID instead of assuming it's always "default" as we do after this patch * Add a way of indicating in `.jj/` that the repo lives elsewhere and make it possible to load a repo from such workspaces * Add a command for creating additional workspaces * Show each workspace's checkout in log output

2022-01-20

working_copy: keep track of operation ID (#13) When there are concurrent operations that want to update the working copy, it's useful to know which operation was the last to successfully update the working copy. That can help use decide how to resolve a mismatch between the repo view's record and the working copy's record. If we detect such a difference, we can look at the working copy's operation ID to see if it was updated by an operation before or after we loaded the repo. If the working copy's record says that it was updated at operation A and we have loaded the repo at operation B (after A), we know that the working copy is stale, so we can automatically update it (or tell the user to run some command to update it if we think that's more user-friendly). Conversely, if we have loaded the repo at operation A and the working copy's record says that it was updated at operation B, we know that there was some concurrent operation that updated it. We can then decide to print a warning telling the user that we skipped updating because of the conflict. We already have logic for not updating the working copy if the repo is loaded at an earlier operation, but maybe we can drop that if we record the operation in the working copy (as this patch does).

2021-12-01

git: start tracking HEAD of underlying Git repo This patch adds a place for tracking the current `HEAD` commit in the underlying Git repo. It updates `git::import_refs()` to record it. We don't use it anywhere yet. This is part of #44.

2021-11-07

working_copy: preserve conflicts in the working copy until markers are removed I realized only recently that we can try to parse conflict markers in files and leave them as conflicted if they haven't changed. If they have changed and some conflict markers have been removed, we can even update the conflict with that partial resolution. This change teaches the working copy to write conflicts to the working copy. It used to expect that the caller had already updated the tree by materializing conflicts. With this change, we also start parsing the conflict markers and leave the conflicts unresolved in the working copy if the conflict markers remain. There are some cases that we don't handle yet. For example, we don't even try to set the executable bit correctly when we write conflicts. OTOH, we didn't do that even before this change. We still never actually write conflicts to the working copy (outside of tests) because we currently materialize conflicts in `MutRepo::check_out()`. I'll change that next.

2021-10-07

backend: remove unused `Commit::is_pruned` (#32)

2021-08-04

view: add support for ref-based branches and tags to model I've finally decided to copy Git's branching model (issue #21), except that I'm letting the name identify the branch across remotes. Actually, now that I think about, that makes them more like Mercurial's "bookmarks". Each branch will record the commit it points to locally, as well as the commits it points to on each remote (as far as the repo knows, of course). Those records are effectively the same thing as Git's "remote-tracking branches"; the difference is that we consider them the same branch. Consequently, when you pull a new branch from a remote, we'll create that branch locally. For example, if you pull branch "main" from a remote called "origin", that will result in a local branch called "main", and also a record of the position on the remote, which we'll show as "main@origin" in the CLI (not part of this commit). If you then update the branch locally and also pull a new target for it from "origin", the local "main" branch will be divergent. I plan to make it so that pushing "main" will update the remote's "main" iff it was currently at "main@origin" (i.e. like using Git's `git push --force-with-lease`). This commit adds a place to store information about branches in the view model. The existing git_refs field will be used as input for the branch information. For example, we can use it to tell if "refs/heads/main" has changed and how it has changed. We will then use that ref diff to update our own record of the "main" branch. That will come later. In order to let git_refs take a back seat, I've also added tags (like Git's lightweight tags) to the model in this commit. I haven't ruled out *also* having some more persistent type of branches (like Mercurials branches or topics).

2021-07-25

view: add support for conflicting git refs in the model This adds support for having conflicting git refs in the view, but we never create conflicts yet. The `git_refs()` revset includes all "add" sides of any conflicts. Similarly `origin/main` (for example) resolves to all "adds" if it's conflicted (meaning that `jj co origin/main` and many other commands will error out if `origin/main` is conflicted). The `git_refs` template renders the reference for all "adds" and adds a "?" as suffix for conflicted refs. The reason I'm adding this now is not because it's high priority on its own (it's likely extremely uncommon to run two concurrent `jj git refresh` and *also* update refs in the underlying git repo at the same time) but because it's a building block for the branch support I've planned (issue #21).

2021-05-10

cli: record full argv in operation log When using the command line interface (which is the only interface so far), it seems more useful to see the exact command that was run than a logical description of what it does. This patch makes the CLI record that information in the operation metadata in a new key/value field. I put it in a generic key/value field instead of a more specialized field because the key/value field seems like a useful thing to have in general. However, that means that we "have to" do shell-escaping when saving the data instead of leaving the data unescaped and adding the shell-escaping when presenting it. I added very simple shell-escaping for now.

2021-01-16

view: add tracking of "public" heads (copying Mercurial's phase concept) Mercurial's "phase" concept is important for evolution, and it's also useful for filtering out uninteresting commits from log output. Commits are typically marked "public" when they are pushed to a remote. The CLI prevents public commits from being rewritten. Public commits cannot be obsolete (even if they have a successor, they won't be considered obsolete like non-public commits would). This commits just makes space for tracking the public heads in the View.

2021-01-11

view: start tracking git refs Git refs are important at least for understanding where the remote branches are. This commit adds support for tracking them in the view and makes `git::import_refs()` update them. When merging views (either because of concurrent operations or when undoing an earlier operation), there can be conflicts between git ref changes. I ignored that for now and let the later operation win. That will probably be good enough for a while. It's not hard to detect the conflicts, but I haven't yet decided how to handle them. I'm leaning towards representing the conflicting refs in the view just like how we represent conflicting files in the tree.

2020-12-24

protobuf: generate code at build-time I had tried to generate the protobuf code at build time many months ago, but decided against it because it slowed down the build too much. I didn't realize there was the "cargo:rerun-if-changed=<filename>" feature that time. Given that that exists, it seems like an obvious win to generate the source code at build time. I put the generated sources in `$OUT_DIR` (where [1] says they should be), then include them in the `protos` module by using the `include!` macro. The biggest problem with that is that I couldn't get IntelliJ to understand it, even after enabling the experimental features described in [2]. [1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation [2] https://github.com/intellij-rust/intellij-rust/issues/1908#issuecomment-592773865

2020-12-12

import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo