From: "Dale R. Worley" <wor...@alum.mit.edu>
Sent: Thursday, July 18, 2013 11:07 PM
From: "Philip Oakley" <philipoak...@iee.org>
Sounds like the 'git gc' needs an option to deliberately prune
files and/or large objects for such a case. Maybe something to
on the main Git list - no doubt some discussion as to what the
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 https://groups.google.com/groups/opt_out.