From: "Dale R. Worley" <>
Sent: Thursday, July 18, 2013 11:07 PM
From: "Philip Oakley" <>

Sounds like the 'git gc' needs an option to deliberately prune specific files and/or large objects for such a case. Maybe something to discuss on the main Git list - no doubt some discussion as to what the command
format would be and why it whould be relevenant and any regression

Well, you can get close to that by setting "--prune=now".  Normally
"git gc" won't remove objects to which there are no pointers until 2
weeks after the object was created.  But "--prune=now" lets "git gc"
eliminate them immediately if they are dangling.

If the file gets recorded in a commit, but the commit is rolled back
(by resetting the branch tip to an earlier commit), then the reflog
for the branch may retain a pointer to the now-unused commit.  You can
get around that by setting gc.reflogExpire.

There's more information in the "git gc" manual page.


I had a look at the manual pages after I posted and thought that gc may be able to add a large file option such that anything above the bigFileThreshold could be removed early (rather than waiting for the various time outs - may need additional --force).

Or that 'git rm', as an opposite to 'git add', may also allow a --gc option that would again allow new wrongly added file to be garbage collected straight away. Otherwise, as you say, they can clog up a repo with cruft, and that we could distinguish between our normal 'keep history logs as a fallback' case and the 'I made a big mistake so just kill this specific bit' case. Like you say, there are many clean up options, its just that sometimes they will clean up to much (being date based, rather than size based).



You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to