Shawn Pearce <spearce@xxxxxxxxxxx> writes:
> Junio C Hamano <junkio@xxxxxxx> wrote:
>> Now if we fix dumb transport downloaders, then we could even
>> make a convention that the packs named pack-[0-9a-f]{40}.pack
>> are archive packs. And git-repack can even have a convention
>> that .git/objects/pack/pack-active.(pack|idx) is the active
>> pack.
>
> Seems reasonable.
>
> I take it you are proposing that a dumb transport always downloads
> pack-active.pack as pack-n{40}.pack where the dumb protocol
> downloader computed the correct pack name from its contents. Thus
> any remote pack downloaded over a dumb transport is automatically
> treated as a historical pack by the receiving repository.
It is a lot lot lot stronger than that. If the dumb transport
(or git in general) uses [0-9a-f]{40} part as the assuarance
mechanism to avoid packname collisions, it should be prepared to
recompute the correct name for not just pack-acrive but _all_
remote packs and store them under the right name.
Also, if repack uses the convention to treat pack-active.* as
the active pack, it might make sense for dumb transport to use
that as a clue and explode what the other side calls pack-active.*
upon reception. For the purpose of repacking decision for the
person at the other end, they are subject for frequent repacking,
so maybe we should treat it as such.
> [snipped and re-ordered]
>> It first downloads the .idx files, so it can compute the
>> _right_ packname using the sorted object names recorded there
>
> Why trust the .idx? I've seen you post that the .idx is purely
> a local matter. The "smart" Git protocol only receives the .pack
> from the remote and computes the .idx locally or unpacks it to loose
> objects locally; why should a dumb transport trust the remote .idx?
Remote .idx is paired with remote .pack and must be able to
access into .pack otherwise the remote person could not use the
pack locally ;-). Note that we are not talking about malicious
repository.
The issue here is not about _trusting_, but adjusting its name
to its contents to match your local convention, which is what
the recent pack-objects spits out to its standard output. Older
versions of pack-objects named the resulting pack with pretty
much randomly (it used to use SHA-1 checksum of object names in
input order, not in index order which is sorted, so the same
pack _could_ have different names), and its output files should
be considered valid packs if they are still around.
--
VGER BF report: S 0.999988
-
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