pub struct Proposal {
pub identity: Identity,
pub target_ref: String,
}Expand description
Everything one proposal is bound to, derived from the checkout.
Fields§
§identity: IdentityThe change, workspace and idempotency key, derived together.
target_ref: StringBranch the proposal asks to land on, as a full refname.
Implementations§
Source§impl Proposal
impl Proposal
Sourcepub fn revision_ref(&self, commit: &str) -> String
pub fn revision_ref(&self, commit: &str) -> String
The refname one revision of this proposal is pushed to.
Named by the commit, under the proposal’s own namespace, and so append-only: re-proposing after an amend or a rebase adds a ref rather than moving one. Two properties follow, and both are why this is not simply a branch.
First, no force-push. A branch would refuse an amended commit as a non-fast-forward, and the repair for that is the force-push this project refuses everywhere else.
Second, and the reason worth the odd-looking refname: every
revision the op log records stays fetchable. A checkpoint puts a
revision hash in the log permanently; if the ref that made its
objects reachable were overwritten, the log would go on naming a
revision the repository could no longer produce. Gerrit keeps
each patchset under refs/changes/NN/NNNN/P for the same reason.
The namespace is deliberately outside refs/heads/: these are
object anchors, not branches, and a clone should not grow one
local branch per revision of every open proposal. The current
revision of a change is revision_id in the view, never the
newest ref.
Sourcepub fn review_target(&self, repo: &str) -> String
pub fn review_target(&self, repo: &str) -> String
The repo:ref spelling RequestReview records as the
destination, which is what per-ref review policy reads.