Re: [PATCH] gc: call "prune --expire 2.weeks.ago"

Pieter de Bie [off-list ref] writes:

On Mar 12, 2008, at 6:01 PM, Jeff King wrote:

quoted

On Wed, Mar 12, 2008 at 05:05:51PM +0100, Johannes Schindelin wrote:

quoted

quoted

I'd really like it to be at least 2 weeks

Could you back that up with an explanation, as to why?

I assume it's "because I wouldn't want to lose work I had done within
the last two weeks." Yes, I know that this expiration is actually
after
the reflog has already expired

Ah, I hadn't realised that. Then I don't really care, one week sounds
fine too. 2 weeks just seemed a bit short, as the default reflog is 30
days. But if it's 2 weeks after the 30 days, that should be more than
enough

Wasn't the default 90 days?

In any case, after 90 days, my reading of the code is that these loose
ones become unreachable, and when we look at their timestamps, we notice
that they are already more than 2 weeks old, and they will immediately be
removed.

So it won't be "2 weeks after X", either.

Hi,

On Wed, 12 Mar 2008, Junio C Hamano wrote:

In any case, after 90 days, my reading of the code is that these loose 
ones become unreachable, and when we look at their timestamps, we notice 
that they are already more than 2 weeks old, and they will immediately 
be removed.

Yes.

In any case, most likely these objects would have been packed anyway 
during that period, so they would have been pruned by the repack called by 
git-gc.

My patch really, really is about _unreferenced_ loose objects, i.e. 
something you get by multiple "git add"s without commits.  And by merge 
conflicts.

IOW by objects that were never referenced by commit objects.

Ciao,
Dscho