On Tue, Oct 09 2018, Martin Langhoff wrote: > Hi folks, > > Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo > I hit the gc error: > > warning: There are too many unreachable loose objects; run 'git prune' > to remove them. > gc --auto: command returned error: 255 > > I don't seem to be the only one -- > https://stackoverflow.com/questions/35738680/avoiding-warning-there-are-too-many-unreachable-loose-objects-during-git-svn > > Looking at code history, it dropped the ability to pass options to git > repack when it was converted it to using git gc. > > Experimentally I find that tweaking it to run git gc --auto > --prune=5.minutes.ago works well, while --prune=now breaks it. > Attempts to commit fail with missing objects. > > - Why does --prune=now break it? Perhaps "gc" runs in the background, > and races with the commit being prepared? > > - Would it be safe, sane to apply --prune=some.value on _clone_? > > - During _fetch_, --prune=some.value seems risky. In a checkout being > actively used for development or merging it'd risk pruning objects > users expect to be there for recovery. Would there be a safe, sane > way? > > - Is there a safer, saner value than 5 minutes? What you've found is the least sucky way to work around this right now, but see my https://public-inbox.org/git/87inc89j38.fsf@xxxxxxxxxxxxxxxxxxx/ and https://public-inbox.org/git/87d0vmck55.fsf@xxxxxxxxxxxxxxxxxxx/ for some prior (and recent) discussion of this problem on-list. FWIW this has nothing to do with git-svn per-se, and also e.g. happens to me when I do a 'git fetch --all' sometimes on git.git.
