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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Mar 12, 2008, 20:25 UTC
Message-ID: <47D83C53.7000602@nrlssc.navy.mil>
In-Reply-To: <alpine.LSU.1.00.0803122058430.1656@racer.site>

Johannes Schindelin wrote:

Show 15 quoted lines

> Hi,
> 
> On Wed, 12 Mar 2008, Brandon Casey wrote:
> 
>> I think git-prune is seldomly used by normal users for the reasons Dscho 
>> described, and I think once the behavior implemented by his patch 
>> becomes standard it will never be used by normal users (except the ones 
>> who always use --prune for the reasons Geert Bosch described, and 
>> they'll probably want the new behavior). So I think git-prune will sink 
>> a little lower into plumbing and common users won't need to know 
>> anything about pruning, and only sophisticated users will need to know 
>> git-prune.
> 
> But because we are nice people, we will deprecate --prune before we remove 
> it, should we go that route at all.

I am not suggesting that git-gc stop parsing --prune and instead start erroring out on it. If it is ok to change the behavior of git-gc, it seems like it is ok to change the behavior of 'git-gc --prune' in the same way, especially if the change makes it less destructive.

I would suggest not having the somewhat ambiguous state of 'git-gc' prunes one way and 'git-gc --prune' prunes in another more dangerous way. And only one is controlled by a config option named gc.pruneExpire (_and_ it's not the obvious usage of git-gc which actually has the word 'prune' on the command line).

So I hope making --prune a noop fits your definition of nice deprecation.

-brandon