Protect dirt blobs in all trees, not just trees of protected refs #149
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
javabrett
added a commit
to javabrett/bfg-repo-cleaner
that referenced
this pull request
Jun 1, 2016
javabrett
added a commit
to javabrett/bfg-repo-cleaner
that referenced
this pull request
Feb 6, 2018
…ot just in protected refs' trees. Fixed rtyley#49, rtyley#53, rtyley#138. Added objectId exclusion filters during tree blob-cleaning, such that blobs that exist in the trees of protected refs as stored in the census (AKA dirt) are protected not only in those trees, but in any other trees in which they occur in in the walked-history. This prevents the perception that those files are being deleted in-history and then re-added in the final re-written commit, which is the protected HEAD (with dirt) and its untouched tree. This is more a perception because Git does not track the history of individual files, but it does show diffs and logs that indicate such changes, and the behaviour prior to this change is to remove protected blobs from non-protected history trees, retaining them only in the final HEAD ref, which then shows as an add in that commit when logs/diffs are taken. This change is convenient if your clean-up selectors (by name, or size) do select some dirt (files still in HEADs that you want to keep) but you don't want those files to appear as if they were recently added to HEAD.
The protected submodule test has a side-effect brought about by the re-use of the same empty file for foo.txt, moo.txt and the submodule bar/comp. Because the same file blob is used, foo.txt when removed from history was no longer removed because it was protected by bar/comp in master HEAD. This re-writes the commits in that repository so that moo.txt and bar/comp are different blobs to foo.txt, so that foo.txt can be removed from the history and the test pass.
javabrett
force-pushed
the
blob-protection-history
branch
from
61d9c32
to
5eca2e6
Compare
|
Any updates on when this will be merged? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR possibly sparks some debate, as there are philosophical aspects of what BFG should do with protected trees and the dirt they contain, and the fact that Git tracks trees/commits and not file-history, but the fact remains that most runners of BFG expect that blobs in protected trees don't appear to move around in the history (pulled-up to HEAD) as they do now as a result of the way Git represents history, logs and diffs.
To that end, I'm interested in discussions on:
objectIdlookup check can be measured?Things I haven't considered ... if the file was updated, I believe it will appear to
git logas an add at the point that the protected version of the file was first committed.This PR was hacked out of a divergent branch, but hopefully it is OK. The test-change was required because of reused empty files in the test repo.