PROTECTING TREES :
Want to leave the tree unchanged for all commits at the tips of refs the user thinks are important.
What if you think a Tag is important? Or a tree?
If a tag points to a:
- commit - that commit may change, but it's tree must stay the same
- tree - who the fuck tags tree anyway? if I've been asked to protect it, that suggests that it's supposed to be inviolate
- blob - that blob will continue to be referenced by the repo, not disappear, but not be cleaned either, as we currently clean at TreeBlob level
We can take a shortcut here by just pushing all hallowed trees straight into the memo collection
This does mean that we will never notice, or be able to report, if somebody sets a rule that 'cleans' (alters) a hallowed tree
It might also have somewhat unexpected consequences if someone hallows a very 'simple' directory that occurs often
PROTECTING BLOBS :
If a user wants to protect the tip of a ref, all blobs will be retained. There is no space-saving or secrets-kept
by deleting, tampering with those blobs elsewhere. And if you have some big-old blob like a jar that you have
used consistently throughout the history of your project, it benefits no-one to remove it- in fact it's actively
harmful.
We explicitly protect blobs (rather than just allowing them to fall under the protection given to Trees) precisely
because these blobs may historically have existed in other directories (trees) that did not appear in the
protected tips, and so would not be protected by Tree protection.
PROTECTING TAGS & COMMITS :
This just means protecting the Trees & Blobs under those Tags and Commits, as specified above. Changing other
state - such as the message, or author, or referenced commit Ids (and consequently the object Id of the target
object itself) is very much up for grabs. I gotta change your history, or I've no business being here.
PROTECTING TREES : Want to leave the tree unchanged for all commits at the tips of refs the user thinks are important. What if you think a Tag is important? Or a tree?
If a tag points to a: - commit - that commit may change, but it's tree must stay the same - tree - who the fuck tags tree anyway? if I've been asked to protect it, that suggests that it's supposed to be inviolate - blob - that blob will continue to be referenced by the repo, not disappear, but not be cleaned either, as we currently clean at TreeBlob level
We can take a shortcut here by just pushing all hallowed trees straight into the memo collection This does mean that we will never notice, or be able to report, if somebody sets a rule that 'cleans' (alters) a hallowed tree It might also have somewhat unexpected consequences if someone hallows a very 'simple' directory that occurs often
PROTECTING BLOBS : If a user wants to protect the tip of a ref, all blobs will be retained. There is no space-saving or secrets-kept by deleting, tampering with those blobs elsewhere. And if you have some big-old blob like a jar that you have used consistently throughout the history of your project, it benefits no-one to remove it- in fact it's actively harmful.
We explicitly protect blobs (rather than just allowing them to fall under the protection given to Trees) precisely because these blobs may historically have existed in other directories (trees) that did not appear in the protected tips, and so would not be protected by Tree protection.
PROTECTING TAGS & COMMITS : This just means protecting the Trees & Blobs under those Tags and Commits, as specified above. Changing other state - such as the message, or author, or referenced commit Ids (and consequently the object Id of the target object itself) is very much up for grabs. I gotta change your history, or I've no business being here.