Package

com.madgag.git.bfg.cleaner

protection

Permalink

package protection

Visibility
  1. Public
  2. All

Type Members

  1. case class ProtectedObjectCensus(protectorRevsByObject: Map[RevObject, Set[String]] = Map.empty, treeProtection: Map[RevTree, Set[RevObject]] = Map.empty, directBlobProtection: Map[ObjectId, Set[RevObject]] = Map.empty, indirectBlobProtection: Map[ObjectId, Set[RevTree]] = Map.empty) extends Product with Serializable

    Permalink

  2. case class ProtectedObjectDirtReport(revObject: RevObject, originalTreeOrBlob: RevObject, replacementTreeOrBlob: Option[ObjectId]) extends Product with Serializable

    Permalink

    The function of the ProtectedObjectDirtReport is tell the user that this is the stuff they've decided to protect in their latest commits - it's the stuff The BFG /would/ remove if you hadn't told it to hold back,

    The function of the ProtectedObjectDirtReport is tell the user that this is the stuff they've decided to protect in their latest commits - it's the stuff The BFG /would/ remove if you hadn't told it to hold back,

    revObject

    - the protected object (eg protected because it is the HEAD commit, or even by additional refs)

    originalTreeOrBlob

    - the unmodified content-object referred to by the protected object (may be same object)

    replacementTreeOrBlob

    - an option, populated if cleaning creates a replacement for the content-object

Value Members

  1. object ProtectedObjectCensus extends Serializable

    Permalink

    PROTECTING TREES : Want to leave the tree unchanged for all commits at the tips of refs the user thinks are important.

    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.

  2. object ProtectedObjectDirtReport extends Serializable

    Permalink

Ungrouped