4 ms·

Cleaning up the mess _after_ firing the BFG is less of a no-brainer. Getting rid of the bad object is easy. But afterward I have to arrange for 350 developers

by mjd 8y ago

Cleaning up the mess _after_ firing the BFG is less of a no-brainer. Getting rid of the bad object is easy. But afterward I have to arrange for 350 developers to switch simultaneously to the rewritten repository. The article discusses an attempt to find a way to avoid this much larger and much more difficult problem.

gbacon 8y ago
Handling intentionally deleted objects does seem like a missing use case in git and not a huge leap in terms of the implementation.
- mjd 8y ago
  I think the concern here is the security implications. Suppose commit X contains some family of configuration files F1, F2, ... that lock down security. Someone, intentionally or otherwise, retroactively destroys F23 in commit X using your proposed feature. Now the security configuration at commit X could have an exploitable loophole. Later on, a serious problem is discovered in the production deployment and the deployed version is rolled back to commit X, but without crucial file F23. Git's current design makes this sort of scenario impossible. Any tampering with commit X after the fact is immediately detectable, and Git will raise an alarm and refuse to check out the commit.
  - gbacon 8y ago
    I was thinking more along the lines of what you were attempting to do locally but with downstream effect: mark the blob itself as intentionally deleted rather than missing or corrupted. This would leave all hashes the same, which sidesteps the much larger coordination problem. To cover the rollback case in your comment, give git checkout a safe mode (either with the default being safe and requiring —-force to override or an explicit —-safe) that fails if the tree-ish points to any deleted blob. How to propagate this change is a delicate matter because any fetch may reach back and destructively update my local clone. When I’ve wished for this feature, it has always been in the context of a central team repository. Being able to delete an object from the central repository at least has the benefit of subsequent clones not being bloated by the 350-megabyte file. Presumably people with access to the team’s central repository can be trusted to wield this power responsibly. Other members of the team may optionally run the hypothetical git delete-object ffff9999 to shrink their respective clones. Leaving it as plumbing to be run on a repository to which one has administrative access seems like a decent balance. This could be a potentially expensive operation because replacing a packed object with a known-but-deleted object would trigger a repack. The ripple effect of this new special case — new object type, really — would be nontrivial and a change that would break backward compatibility.

by mjd 8y ago

gbacon 8y ago

Handling intentionally deleted objects does seem like a missing use case in git and not a huge leap in terms of the implementation.

mjd 8y ago
I think the concern here is the security implications. Suppose commit X contains some family of configuration files F1, F2, ... that lock down security. Someone, intentionally or otherwise, retroactively destroys F23 in commit X using your proposed feature. Now the security configuration at commit X could have an exploitable loophole. Later on, a serious problem is discovered in the production deployment and the deployed version is rolled back to commit X, but without crucial file F23. Git's current design makes this sort of scenario impossible. Any tampering with commit X after the fact is immediately detectable, and Git will raise an alarm and refuse to check out the commit.
- gbacon 8y ago
  I was thinking more along the lines of what you were attempting to do locally but with downstream effect: mark the blob itself as intentionally deleted rather than missing or corrupted. This would leave all hashes the same, which sidesteps the much larger coordination problem. To cover the rollback case in your comment, give git checkout a safe mode (either with the default being safe and requiring —-force to override or an explicit —-safe) that fails if the tree-ish points to any deleted blob. How to propagate this change is a delicate matter because any fetch may reach back and destructively update my local clone. When I’ve wished for this feature, it has always been in the context of a central team repository. Being able to delete an object from the central repository at least has the benefit of subsequent clones not being bloated by the 350-megabyte file. Presumably people with access to the team’s central repository can be trusted to wield this power responsibly. Other members of the team may optionally run the hypothetical git delete-object ffff9999 to shrink their respective clones. Leaving it as plumbing to be run on a repository to which one has administrative access seems like a decent balance. This could be a potentially expensive operation because replacing a packed object with a known-but-deleted object would trigger a repack. The ripple effect of this new special case — new object type, really — would be nontrivial and a change that would break backward compatibility.