pub struct RefCas<'a> {
pub name: String,
pub old: Option<Oid<'a>>,
pub new: Option<Oid<'a>>,
}Expand description
One ref edit with the value the caller expects to find.
This is the field RefUpdate lacks, and its absence is the whole reason
git push --atomic could not be expressed: GitOps::put_refs is a batch
without compare-and-swap and GitOps::update_ref is compare-and-swap
without a batch, and --atomic is defined as both at once. Neither
composes into the other — applying a batch one CAS at a time is exactly the
partial application --atomic promises never to happen.
Borrowed, like every other oid in this contract: a receive-pack command line
is <old> <new> <ref> and both oids are already slices of the pkt-line the
caller is holding.
Fields§
§name: String§old: Option<Oid<'a>>What the caller believes is there. None means must not exist — a
create that must fail if anything is already at name.
There is deliberately no third “don’t care” state. receive-pack always
names an old value (all-zeroes for a create), so a caller that genuinely
does not care wants GitOps::put_refs, which is the batch that makes no
claim about the previous value.
new: Option<Oid<'a>>The new value. None deletes.