Re: Ideas to speed up repacking

> Duy Nguyen <pclouds@gmail.com> writes:
>
>>> If nothing else has happened in the repository, perhaps, but I
>>> suspect that the real problem is how you would prove it.  For
>>> example, I am guessing that your Scenario 4 could be something like:
>>>
>>>     : setup #1
>>>     $ git repack -a -d -f
>>>     $ git prune
>>>
>>>     : scenario #4
>>>     $ git commit --allow-empty -m 'new commit'
>>>
>>> which would add a single loose object to the repository, advancing
>>> the current branch ref by one commit, fast-forwarding relative to
>>> the state you were in after setup #1.
>>>
>>> But how would you efficiently prove that it was the only thing that
>>> happened?
>>
>> Shawn mentioned elsewhere that we could generate bundle header in and
>> keep it in pack-XXX.bh file at pack creation time. With that
>> information we could verify if a ref has been reset, just fast
>> forwarded or even deleted.
>
> With what information? If you keep the back-then-current information
> and nothing else, how would you differentiate between the simple
> scenario #4 above vs 'lost and new' two commit versions of the
> scenario?  The endpoints should both show that one ref (and only one
> ref) advanced by one commit, but one has cruft in the object
> database while the other does not.