git svn clone/fetch hits issues with gc --auto
- From
Martin Langhoff <martin.langhoff@gmail.com>
- Date
- Oct 9, 2018, 22:51 UTC
- Message-ID
- <CACPiFCKQq--xrMf1nF=1MmC+eESE_aKms3yogoRwCY=YxcOWXA@mail.gmail.com>
- In-Reply-To
- <CACPiFCJZ83sqE7Gaj2pa12APkBF5tau-C6t4_GrXBWDwcMnJHg@mail.gmail.com>
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?
cheers,
m
-- martin.langhoff@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted ~ http://github.com/martin-langhoff by shiny stuff -- martin.langhoff@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted ~ http://github.com/martin-langhoff by shiny stuff