Nicolas Pitre wrote:
quoted text > On Tue, 11 Sep 2007, Andreas Ericsson wrote:
>
>> Andreas Ericsson wrote:
>>> Nicolas Pitre wrote:
>>>> On Tue, 11 Sep 2007, Andreas Ericsson wrote:
>>>>
>>>>> So how does one unpack a packfile to extract the loose objects?
>>>>>
>>>>> mv .git/objects/pack/*.pack /tmp/git-packs
>>>>> for p in /tmp/git-packs/*.pack; do git unpack-objects < $p; done
>>>>>
>>>>> ?
>>>>>
>>>>> Seems like an awful lot of trouble. I'll look into patching
>>>>> builtin-pack-objects.c instead to accept an "--ignore-reflog" flag and
>>>>> prune
>>>>> reflog-accessible objects. Will that break anything fundamental?
>>>> Why would you want to extract loose objects in the first place? That
>>>> appears to be a really funny goal to me.
>>>>
>>> I didn't. I wanted to get rid of superfluous loose objects in the odb.
>>>
>> I'll expand on this a bit.
>>
>> I thought that the loose tips weren't being pruned because they were packed.
>> I had forgotten about the reflog protecting them from deletion, so in order
>> to get rid of the loose tips after I was done getting my data back, I wanted
>> to prune all the objects. Since I believed that would require all the objects
>> to be loose, I sought to unpack the packs I had created.
>>
>> I realize now that unpack-objects *must* work as Junio explained in another
>> email (ie, not unpack anything that's already in the odb), as unpack-objects
>> is used to explode the packs received when pulling (or being pushed to).
>> Should it have different semantics, git users would otherwise risk having
>> known good objects clobbered by bad ones via some social engineering and a
>> pull from a malign repo.
>
> Note that if you truly want to get rid of unreferenced objects, you
> simply have to run 'git gc' or 'git repack -a -d'. The unreferenced
> objects will vanish, even if they were already packed previously. The
> new pack will simply not contain them anymore.
>
That's what I thought, but because of the reflog they aren't pruned. Since
I never use the reflog I didn't remember that it was that particular feature
that protected my refs, and so the only thing I could think of that made them
*not* go away was the fact that they were packed.
--
Andreas Ericsson
andreas.ericsson@op5.se
OP5 AB
www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html