All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Kevin Ballard <kevin@sb.org>, Git Mailing List <git@vger.kernel.org>
Subject: Re: git filter-branch should run git gc --auto
Date: Tue, 22 Jan 2008 18:54:08 -0800	[thread overview]
Message-ID: <1201056848.16972.102.camel@brick> (raw)
In-Reply-To: <7v1w89qmw3.fsf@gitster.siamese.dyndns.org>

On Tue, 2008-01-22 at 18:46 -0800, Junio C Hamano wrote:
> 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

  parent reply	other threads:[~2008-01-23  2:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 12:17 git-svn should default to --repack Kevin Ballard
2008-01-18 15:56 ` Karl Hasselström
2008-01-18 20:44   ` Junio C Hamano
2008-01-19 12:35     ` Karl Hasselström
2008-01-19 15:05       ` Kevin Ballard
2008-01-19 22:36       ` [PATCH] Let "git svn" run "git gc --auto" occasionally Karl Hasselström
2008-01-19 22:50         ` Harvey Harrison
2008-01-20  3:37           ` Eric Wong
2008-01-20  9:34             ` Karl Hasselström
2008-01-20 19:17               ` Junio C Hamano
2008-01-21 22:48                 ` Eric Wong
2008-01-22  0:30                   ` Junio C Hamano
2008-01-22  0:39                     ` Eric Wong
2008-01-22  1:52                       ` Junio C Hamano
2008-01-23  2:43                         ` git filter-branch should run git gc --auto Kevin Ballard
2008-01-23  2:46                           ` Junio C Hamano
2008-01-23  2:52                             ` Junio C Hamano
2008-01-23  3:03                               ` Kevin Ballard
2008-01-23  2:54                             ` Harvey Harrison [this message]
2008-01-23  2:58                             ` Kevin Ballard
2008-01-23  5:07                               ` Sam Vilain
2008-01-23  8:18                                 ` Kevin Ballard
2008-01-23  6:44                             ` Mike Hommey
2008-01-23 13:00                               ` Johannes Schindelin
2008-01-23 19:22                               ` Junio C Hamano
2008-02-03 16:55                   ` [PATCH 0/2] "git svn" and "git gc --auto" Karl Hasselström
2008-02-03 16:56                     ` [PATCH 1/2] git-svn: Don't call git-repack anymore Karl Hasselström
2008-02-03 16:56                     ` [PATCH 2/2] Let "git svn" run "git gc --auto" occasionally Karl Hasselström
2008-01-20 21:39               ` [PATCH 1/2] git-svn: Don't call git-repack anymore Karl Hasselström
2008-01-20 21:40               ` [PATCH 2/2] Let "git svn" run "git gc --auto" occasionally Karl Hasselström

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1201056848.16972.102.camel@brick \
    --to=harvey.harrison@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kevin@sb.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.