Re: [PATCH v2 3/3] pack-objects: honor '.keep' files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
> Brandon Casey <casey@xxxxxxxxxxxxxxx> writes:
> 
>>   <-a>
>>     -create a new pack containing all objects required by the repository
>>      including those accessible through alternates, but excluding objects
>>      in _local_ packs with .keep
> 
> I have a feeling that it is debatable if this "fattening to dissociate
> from alternates" is what people want.

I'm not sure I understand you here.

Andreas has suggested previously that 'repack -a' should pack everything,
including objects in packs with .keep. Is that what you mean?

With my current understanding it seems that that would muddy the semantics
of repack. If -a does not honor packs with .keep, then would it be intuitive
to expect that adding -l (i.e. exclude alternate packed objects) _would_
honor .keep?

>>   <-a -l>
>>      -Restrict operation to only local objects. Only has any effect with -a|-A.
>>      -Like -a, but additionally exclude objects in packs accessible through
>>       alternates.
> 
> Presumably you meant "exclude objects accessible through alternates,
> either in packs or in loose form"?  If so then I think it is a good thing
> to have.

Would that be an enhancement to the current behavior? I don't think I saw
any mechanism to exclude packing remote loose objects.

The documentation for pack-objects --local says:

  --local
         This flag is similar to --incremental; instead of ignoring  all
         packed objects, it only ignores objects that are packed and not
         in the local object store (i.e. borrowed from an alternate).

It only mentions packed alternate objects.

> 
> I am not sure if listing the behaviour by combination of flags is a good
> way to start thinking about this.  Wouldn't it be more productive to list
> what kinds of repacking are needed, and then label them with combination
> of flags?  Otherwise you would miss a potentially useful operation that
> cannot be expressed with the current set of flags you have.

I agree. I made a list of the options because I was trying to understand what
effect each option had, then I turned it into an email.

> I think the useful kinds are only these five:
> 
>  - scoop loose objects that exist in local repository into a new pack,
>    without touching existing packs at all; exclude anything available in
>    any existing pack or in alternate repository (either loose or packed);
>
>  - pack everything that is needed by the local ref, except the ones that
>    are borrowed from alternate repositories (either loose or packed), into
>    a single new pack.  There are two variants of this: eject what is
>    currently packed but unnecessary into loose format when existing local
>    packs are replaced with the new pack, or lose them (i.e. -A).
>
>  - fatten local repository by packing everything that is needed by the
>    local ref into a single new pack, including things that are currently
>    borrowed from alternates.  There are two variants of this: eject what
>    is currently packed but unnecessary into loose format when existing
>    local packs are replaced with the new pack, or lose them (i.e. -A).

You didn't say when local .keep should be honored, i.e. objects in local
packs with .keep should be excluded from repacking. always, never, only
with -l, new repack option?

-brandon

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux