Git development
 help / color / mirror / Atom feed
From: Martin Fick <mfick@codeaurora.org>
To: Jeff King <peff@peff.net>
Cc: Mike Hommey <mh@glandium.org>, git@vger.kernel.org
Subject: Re: Preserve/Prune Old Pack Files
Date: Mon, 09 Jan 2017 09:20:05 -0700	[thread overview]
Message-ID: <3341131.K6hMDMB8iT@mfick1-lnx> (raw)
In-Reply-To: <20170109105545.gchfklcuzwhlfbtf@sigill.intra.peff.net>

On Monday, January 09, 2017 05:55:45 AM Jeff King wrote:
> On Mon, Jan 09, 2017 at 04:01:19PM +0900, Mike Hommey 
wrote:
> > > That's _way_ more complicated than your problem, and
> > > as I said, I do not have a finished solution. But it
> > > seems like they touch on a similar concept (a
> > > post-delete holding area for objects). So I thought
> > > I'd mention it in case if spurs any brilliance.
> > 
> > Something that is kind-of in the same family of problems
> > is the "loosening" or objects on repacks, before they
> > can be pruned.
...
> Yes, this can be a problem. The repack is smart enough not
> to write out objects which would just get pruned
> immediately, but since the grace period is 2 weeks, that
> can include a lot of objects (especially with history
> rewriting as you note). It would be possible to write
> those loose objects to a "cruft" pack, but there are some
> management issues around the cruft pack. You do not want
> to keep repacking them into a new cruft pack at each
> repack, since then they would never expire. So you need
> some way of marking the pack as cruft, letting it age
> out, and then deleting it after the grace period expires.
> 
> I don't think it would be _that_ hard, but AFAIK nobody
> has ever made patches.

FYI, jgit does this,

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation


  reply	other threads:[~2017-01-09 16:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <24abd0ed58c25ce832014f9bd5bb2090@codeaurora.org>
2017-01-04 16:11 ` Preserve/Prune Old Pack Files Martin Fick
2017-01-09  6:21   ` Jeff King
2017-01-09  7:01     ` Mike Hommey
2017-01-09 10:55       ` Jeff King
2017-01-09 16:20         ` Martin Fick [this message]
2017-01-09 16:17     ` Martin Fick
2017-01-10  9:14       ` Jeff King

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=3341131.K6hMDMB8iT@mfick1-lnx \
    --to=mfick@codeaurora.org \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=peff@peff.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox