I was very surprised to find that git-svn does not in fact default to --repack. I firmly believe it should. Here's an example as to why it should. I used git-svn to import a repository with 33000 revisions and about 7500 files. It took about 18 hours to import. When it was done, my .git folder had 242001 files that comprised 2.0GB. I ran `git gc -- agressive --prune` and let that sit overnight (I wish it was more verbose, it went for over an hour without printing anything), and that managed to compress the repo down to 334 files and 64MB. Now I have to figure out how to delete the .git folder from my regular backups. http://skitch.com/kballard/r7mn/results-of-git-gc-ono-macports-repo -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Ingo Molnar | [git pull] x86 arch updates for v2.6.25 |
| Anton Salikhmetov | [PATCH -v8 2/4] Update ctime and mtime for memory-mapped files |
git: | |
| Patrick McHardy | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 16/37] dccp: API to query the current TX/RX CCID |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
