Re: [PATCH 2/2] introduce "preciousObjects" repository extension

[Duy Nguyen <pclouds@gmail.com>]

On Wed, Jun 24, 2015 at 3:12 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Jun 23, 2015 at 06:54:11AM -0400, Jeff King wrote:
>
>> diff --git a/builtin/prune.c b/builtin/prune.c
>> index 0c73246..fc0c8e8 100644
>> --- a/builtin/prune.c
>> +++ b/builtin/prune.c
>> @@ -218,6 +218,9 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
>>               return 0;
>>       }
>>
>> +     if (repository_format_precious_objects)
>> +             die("cannot prune in a precious-objects repo");
>> +
>
> By the way, I originally wrote this patch on an older version of git,
> and was surprised that `git gc` broke when I brought it forward. The
> problem was that gc now runs `git prune --worktree`, and my die() was
> affecting that case.
>
> It really seems misplaced to me to make worktree-pruning part of
> git-prune. I imagine the rationale was "well, we are pruning things, so
> let's add an option to this command rather than make a new one". But I
> do not think that follows our usual pattern with gc, which is:
>
>   1. Individual areas of code handle their own cleanup. E.g., "reflog
>      expire", "rerere gc".
>
>   2. We tie them together with "git gc", not with "git prune".
>
> So it seems weird that "git prune --worktree" is a fundamentally
> different command than "git prune". I think by (1), it should be a
> separate "git prune-worktree" (or better yet, "git worktree prune", as
> the start of a command for manipulating the list of multiple-worktrees).
>
> Not a _huge_ deal, but if we want to change it, it would be nice to do so
> now before it is part of a release. Thoughts?

I was misled by the generic name "prune" :) (OK my bad, the document
clearly says it's about object database). Maybe we should make an
alias prune-objects.. And you caught me too late, I also added
prune_shallow() in there.

Multiple worktree feature is not released yet so I still have some
time to move it out. Yeah "git worktree prune" makes sense. I think I
need a way to list worktrees anyway. I didn't find good enough reason
to create "git worktree" back then just for listing..
-- 
Duy