All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mikael Magnusson" <mikachu@gmail.com>
To: "Mark Brown" <broonie@sirena.org.uk>
Cc: "Theodore Tso" <tytso@mit.edu>,
	"Bj?rn Steinbrink" <B.Steinbrink@gmx.de>,
	"Bruce Stephens" <bruce.stephens@isode.com>,
	git@vger.kernel.org
Subject: Re: "git gc" doesn't seem to remove loose objects any more
Date: Mon, 15 Dec 2008 17:59:44 +0100	[thread overview]
Message-ID: <237967ef0812150859g2c506820y740a25be194e9754@mail.gmail.com> (raw)
In-Reply-To: <20081215161212.GE31145@sirena.org.uk>

2008/12/15 Mark Brown <broonie@sirena.org.uk>:
> On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
>> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
>
>> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
>> > so that git prune can drop them. And git gc invokes git prune so that
>> > only unreachable objects older than 2 weeks are dropped.
>
>> To be even more explicit, "git gc" will **unpack** objects that have
>> become unreachable and were currently in packs.  As a result, the
>> amount of disk space used by a git repository can actually go **up**
>> dramatically after a "git gc" operation, which could be surprising for
>> someone who is running close to full on their filesystem, deletes a
>> number of branches from a tracking repository, and then does a "git
>> gc" may get a very unpleasant surprise.
>
> It can also cause things like the "please repack" warning in git gui to
> go off.  This is especially unhelpful since they tend to tell you to go
> and do a gc to resolve the problem.

A thought that occurs to me is to add some sort of flag to git count-objects
that prints the number of objects older than some interval in a separate field.
That way git gui would give less (maybe no) false alarms.

-- 
Mikael Magnusson

  parent reply	other threads:[~2008-12-15 17:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 12:52 "git gc" doesn't seem to remove loose objects any more Bruce Stephens
2008-12-15 13:38 ` Mikael Magnusson
2008-12-15 14:08   ` Bruce Stephens
2008-12-15 14:08   ` Björn Steinbrink
2008-12-15 15:56     ` Theodore Tso
2008-12-15 16:12       ` Mark Brown
2008-12-15 16:59         ` Johan Herland
2008-12-15 16:59         ` Mikael Magnusson [this message]
2008-12-15 17:07       ` Jakub Narebski
2008-12-15 19:38         ` Theodore Tso
2008-12-15 17:11       ` Brandon Casey
2008-12-15 17:38       ` [PATCH] objects to be pruned immediately don't have to be loosened Nicolas Pitre

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=237967ef0812150859g2c506820y740a25be194e9754@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=B.Steinbrink@gmx.de \
    --cc=broonie@sirena.org.uk \
    --cc=bruce.stephens@isode.com \
    --cc=git@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.