Re: Deprecation/Removal schedule

From: Alex Riesen <raa.lkml@gmail.com>
Date: Feb 6, 2007, 13:01 UTC
Message-ID: <81b0412b0702060501u41a3f707pea4bfc58220fd862@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.63.0702061144430.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On 2/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 12 quoted lines

> > >
> > > `git gc` is your friend.  It automatically trims the reflogs, keeping
> > > only the last 90 days worth of entries.  You can tune this with the
> > > `gc.reflogexpire` configuration parameter.
> >
> > git gc (repack -d of it) is too dangerous in a shared repo: it breaks
> > the repos which depend on the master repository, have sent (by some
> > means) some objects over to the master, and accidentally removed
> > the reference, and were pruned afterwards.
>
> We no longer call git-prune automatically in git-gc. You have to say
> "git-gc --prune" to trigger that behaviour.

no. You'd have to stop calling repack as well.

I mean the objects that generally have to be removed and just accidentally was not pinned in the shared repo. Or did you mean that repack will leave unreferenced objects behind in objects/??/files?