Re: git filter-branch should run git gc --auto
- From
- Harvey Harrison <harvey.harrison@gmail.com>
- Date
- Jan 23, 2008, 02:54 UTC
- Message-ID
- <1201056848.16972.102.camel@brick>
- In-Reply-To
- <7v1w89qmw3.fsf@gitster.siamese.dyndns.org>
On Tue, 2008-01-22 at 18:46 -0800, Junio C Hamano wrote:
Show 25 quoted lines
> Kevin Ballard <kevin@sb.org> 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.
And afterwards, you'll probably want to check the rewritten history to make sure it is acceptable before doing a git gc --prune.
Cheers,
Harvey