> I can relate for the most part. I can only think of one instance (in over half a decade) where I felt git's shortcomings: there is no way to get a deleted non-gc'd object from a remote to your local repository, even if you try to reference it by its sha1.
For better or worse (and I've wanted it to work too) it's an intentional security feature that you can only pull objects from a git remote that are reachable by its refs; that way deleted branches (e.g. containing data that wasn't intended for release) are instantly unavailable rather than needing to wait for GC.
Seems like a shaky justification. I understand not offering things that are up for deletion but there wasn't even a way to do git pull --i-really-want-everything or some such.
If you push passwords and keys to your git server, then force-push those things out, you most definitey want to run a gc. Git is a flimsy security layer around this.
Well if you don't have enough access to the remote machine to locally get the objects or run "git branch oops <sha1>", you probably also don't have access to run a gc to prune the objects. In that case the "permissive" alternative would mean that you could not remove access to the objects at all once they'd been pushed. Given that, I can see the justification for the behavior they chose.
For better or worse (and I've wanted it to work too) it's an intentional security feature that you can only pull objects from a git remote that are reachable by its refs; that way deleted branches (e.g. containing data that wasn't intended for release) are instantly unavailable rather than needing to wait for GC.