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. > <-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. 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 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). -- 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
