jj/lib/protos/op_store.proto

89 lines
2.3 KiB
Protocol Buffer
Raw Normal View History

// Copyright 2020 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
syntax = "proto3";
message RefConflict {
repeated bytes removes = 1;
repeated bytes adds = 2;
}
message RefTarget {
oneof value {
bytes commit_id = 1;
RefConflict conflict = 2;
}
}
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-15 08:31:48 +00:00
message RemoteBranch {
string remote_name = 1;
RefTarget target = 2;
}
message Branch {
string name = 1;
// Unset if the branch has been deleted locally.
RefTarget local_target = 2;
// TODO: How would we support renaming remotes while having undo work? If
// the remote name is stored in config, it's going to become a mess if the
// remote is renamed but the configs are left unchanged. Should each remote
// be identified (here and in configs) by a UUID?
repeated RemoteBranch remote_branches = 3;
}
message GitRef {
string name = 1;
// This field is just for historical reasons (before we had the RefTarget
// type). New GitRefs have (only) the target field.
// TODO: Delete support for the old format.
bytes commit_id = 2;
RefTarget target = 3;
}
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-15 08:31:48 +00:00
message Tag {
string name = 1;
RefTarget target = 2;
}
message View {
repeated bytes head_ids = 1;
repeated bytes public_head_ids = 4;
bytes checkout = 2;
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-15 08:31:48 +00:00
repeated Branch branches = 5;
repeated Tag tags = 6;
// Only a subset of the refs. For example, does not include refs/notes/.
repeated GitRef git_refs = 3;
}
message Operation {
bytes view_id = 1;
repeated bytes parents = 2;
OperationMetadata metadata = 3;
}
// TODO: Share with store.proto? Do we even need the timezone here?
message Timestamp {
uint64 millis_since_epoch = 1;
int32 tz_offset = 2;
}
message OperationMetadata {
Timestamp start_time = 1;
Timestamp end_time = 2;
string description = 3;
string hostname = 4;
string username = 5;
map<string, string> tags = 6;
}