I have a large git repository with 17 years of history. After converting it with svn2git, I usually do a 'git repack -a -d -f'. This says 'Nothing new to pack.' Then if I push it to the server (in my case Bit Bucket), and then locate the repository on the server and do repack, it repacks the whole repository. I would like to be able to always repack the whole repo if possible. I can't figure out what the changes are between pushing to the server, that allows the repack. Note, there are no changes made to the repository between the client and server.
Asked
Active
Viewed 914 times
1
-
Do you mean it prints `Nothing new to pack.`? – torek Sep 16 '17 at 14:23
-
Are you experiencing a specific issue that is prompting you to repack your repository? Usually this is handled automatically. – LightBender Sep 16 '17 at 14:37
-
The repo is quite large > 3.4GB, packing and garbage collection shave 1GB off the size of the repo. Repacking improves clone times and improves the performance of Bit Bucket when it is rendering the repo in the web browser. – eeijlar Sep 16 '17 at 15:59
-
@torek: yes, that is what i meant. – eeijlar Sep 16 '17 at 16:02
-
I have amended the question. – eeijlar Sep 16 '17 at 16:04
1 Answers
0
The output you are seeing comes from these source lines:
if (!names.nr && !quiet)
printf("Nothing new to pack.\n");
Here names.nr is the number of SHA-1 ID lines read from the git pack-objects command, when run with the arguments provided in the argv and environment computed earlier in this same code.
What's happening in this case is that whatever svn2git utility you are using is building a single pack file, and for whatever reason, git pack-objects is choosing to leave that file alone.
What I cannot explain is why -a -d -f did not force a repack, because it should. The git pack-objects command should have generated a new pack file with new compression. (I suppose one possibility is that git pack-objects is simply failing entirely on your particular system, but then you should get a complaint about that, too.)
torek
- 448,244
- 59
- 642
- 775