[scrollaway]

Good article. That old tutorial is scary :)

> I screwed up really badly before, merging wrong things together, accidentally deleting data and much more, yet I never lost any data or felt left abandoned by my tool.

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.

This happened to me when some bad changes were force-pushed to a repository on Github and did not have access to a machine which had the latest changes. My repository on Github still knew about the old commits, but they were unreachable by git itself.

[phs2501]

> 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.

[scrollaway]

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.

[avar]

Of course you can't run "git pull --i-really-want-everything", you're the remote attacker this feature is meant to protect against!

The use-case for this is that you're pushing to some shared hosting like GitHub where you can overwrite and delete refs, but you can't force a gc.

You don't want someone to scour your Git commit announcements and see "oops, deleted password!" and go and fetch the deleted SHA1.

[phs2501]

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.

[ecobiker]

It is possible with Github at least - using a combination of the list repo events API & the create commit API.

[drrotmos]

Couldn't you just have (by hand) created a tree/commit/branch referencing the object, pushed it to the server and then fetched it (possibly to a new clone)?

[jordigh]

> That old tutorial is scary :)

And funny!

    Creating a new git archive couldn't be easier

O RLY!