Re: [Gnu-arch-users] Re: [GNU-arch-dev] Re: [ANNOUNCEMENT] /Arch/ embraces `git'

[John A Meinel]

Tom Lord wrote:

>  > I'm a little concerned about accidental collisions, in the baz proposal:
>  > http://wiki.gnuarch.org/Win32FriendlyFormats
>
>  > The SHA checksums are postfixed with a number -1, -2, etc to allow for
>  > collisions that have different contents.
>
> In the context of `git' you could not use numbers like that since there
> is no central authority to allocate them.
What if they were just an artifact of the storage medium? Meaning that
they are not official handles, but just filesystem names.
So that on my machine, I might have a -1, -2, and -3, and if I check
against *your* tree, you may only have -1, which I have to check against
all three of my files before I say you do/don't have a match.

However, I think 2^-160 * 2^-10 is a low enough probability of collision
that we don't have to worry about it. (Even if it is only 2^-80). Again,
we aren't dealing with randomly generated data, you have a meaningful
input. I would guess that would help prevent collisions, but it could go
either way.

> One *could* use a probabilistically unique, user-selected id on the
> other hand.
>
> In Arch-speak, this would be like naming each blob with:
>
>         <sha1>,<size>,<id-tag>
>
> If id-tags have internal structure that reflects their origin
> (e.g., the way I stick "address@hidden" in mine), a blob-db
> based system could filter out blobs whose id-tag statements
> of their origin do not match where the data is coming from.
>
> That would `git' pretty impregnable but at very high practical cost, I
> think.  It would complicate the politics of `git' a lot, making them
> harder to think about.  Perhaps that's something for `git 2.0' (if
> such a thing is ever needed)?
Agreed.

> -t
John
=:->

signature.asc
Description: OpenPGP digital signature