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
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [patch 00/40] 2.6.23-stable review, driver (sans network) changes |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
