Kevin Ballard <kevin@xxxxxx> writes: > I just glanced at git-filter-branch.sh (and I must say I was > incredibly surprised to find out it was a shell script) and it seems > it never runs git-gc or git-repack. Doesn't that end up with the same > problems as git-svn sans git-repack when filtering a large number of > commits? I was just thinking, if I were to git-filter-branch on my > massive repo (in fact, the same repo that started this thread, with > over 33000 commits in the upstream svn repo), even if I just do > something as simple as change the commit msg wont I end up with > thousands of unreachable objects? I shudder to think how many > unreachable objects I would have if I pruned the entire dports > directory off of the tree. > > Am I missing something, or does git-filter-branch really not do any > garbage collection? I tried reading the source, but complex bash > scripts are almost as bad as perl in terms of readability. Theoretically yes, and it largely depends on what you do, but filter-branch goes over the objects that already exists in your repository, and hopefully you won't be rewriting majority of them. So the impact of not repacking is probably much less painful in practice. But again as I said, it largely depends on what you do in your filter. If you are upcasing (or convert to NFD ;-)) the contents of all of your blob objects, you would certainly want to repack every once in a while. - 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
