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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Mar 12, 2008, 19:55 UTC
Message-ID: <47D83532.70103@nrlssc.navy.mil>
In-Reply-To: <m3prtzyens.fsf@localhost.localdomain>

Jakub Narebski wrote:

Show 7 quoted lines

> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> Is 'git-gc --prune' still useful to end users when those in-the-know can use
>> git-prune when they really want all loose unreferenced objects to be removed?
> 
> It is one command less to remember (just like with "git tag --verify"
> and "git verify-tag"), so I'm all for "git gc --prune" to remain.

I think the issue here is that the prune behavior of git-gc is more complex when both 'git-gc' does prune and 'git-gc --prune' does prune, but only one of them is controlled by gc.pruneExpire. From a high level perspective, this is non-obvious and so has to be explicitly outlined in the help text _and_ users have to remember it. The git-gc command and the documentation and suggested work flows can all be simplified by just always doing a safe prune.

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.

-brandon