From: Junio C Hamano <gitster@pobox•com>
To: Duy Nguyen <pclouds@gmail•com>
Cc: Martin Fick <mfick@codeaurora•org>,
Git Mailing List <git@vger•kernel.org>
Subject: Re: Ideas to speed up repacking
Date: Mon, 02 Dec 2013 23:17:24 -0800 [thread overview]
Message-ID: <xmqqli02pfnf.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8DJU2YTE1iNdb=fvo0fVOgLUK2mKXUhjcoJh8Ac0wW_EA@mail.gmail.com> (Duy Nguyen's message of "Tue, 3 Dec 2013 10:27:09 +0700")
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.
>> Also with Scenario #2, how would you prove that the new pack does
>> not contain any cruft that is not reachable? When receiving a pack
>> and updating our refs, we only prove that we have all the objects
>> needed to complete updated refs---we do not reject packs with crufts
>> that are not necessary.
>
> We trust the pack producer to do it correctly, I guess. If a pack
> producer guarantees not to store any cruft, it could mark the pack
> somehow.
That is not an answer. Since when do we design to blindly trust
anybody on the other end of the wire?
next prev parent reply other threads:[~2013-12-03 7:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-02 23:30 Ideas to speed up repacking Martin Fick
2013-12-03 0:44 ` Junio C Hamano
2013-12-03 3:27 ` Duy Nguyen
2013-12-03 7:17 ` Junio C Hamano [this message]
2013-12-03 10:17 ` Duy Nguyen
2013-12-03 17:50 ` Junio C Hamano
2013-12-03 19:26 ` Martin Fick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqli02pfnf.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mfick@codeaurora$(echo .)org \
--cc=pclouds@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox