On 2006-10-10 17:03, Linus Torvalds wrote: > On Tue, 10 Oct 2006, Sam Vilain wrote: >> If using git-repack -a, unreferenced objects are kept behind in the >> pack. This might be the best default, but there are no good ways >> to clean up the packfiles if a lot of rebasing is happening, or >> branches have been deleted. > > Don't do this. Too late: "git repack -a -d" already does it, in contradiction to its manpage. It creates a new pack by following .git/refs, and then deletes all old pack files. > I understand why you want to do it, but the fact is, it's dangerous. > > Right now, "git repack" is actually safe to run even on a repository which > is being modified! And that's actually important, if you have something > like a shared repo that gets re-packed every once in a while from a > cron-job! Don't run it on a shared repo, then. And grab a coffee while it runs. But why force leaf repositories to accumulate garbage? This functionality is just as racy, and just as necessary, as "git-prune". It merely garbage-collects the packs as well. Git seems to collect unreferenced objects faster than the space between the cushions in my sofa, and there ought to be a way to tidy up things. Linus, I see why you neither need nor want this functionality in your typical workflow, but things look different for a downstream developer who engages in a variety of garbage-generating activities like tracking wild trees, rebasing patches and using stgit. I really don't need that unreferenced copy of 2.6.15-rc2-mm1 in my packs anymore. Eran - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html