Re: Git-commits mailing list feed.

[Paul Jakma]

On Sun, 24 Apr 2005, David A. Wheeler wrote:

> Now you just have to FIND the signature of a signed object, i.e. 
> efficiently go the "other way" from signed object to detached 
> signature.  A separate directory with this mapping, or embedding 
> the mapping inside the object directory (HASH.d/<list>) both solve 
> it.

You dont even need it, see my other mail. If:

- the signature is an object and added after the commit object

- tools know that signatures are 'proxies of' or precursors to the
  objects they are signing (which makes sense, a signature by
  definition refers to something else)

- the signature object refers to the object it is signing (eg a
  'Signing <object ID>' header)

Then head can simply be the signature object and tools can find the 
commit by following the 'Signing' field of the signature (they dont 
even need to check the signature is valid). No index lookup needed.

You only need the index for historical verification really, and you 
can always generate an index if needs be. (and have the tools 
maintain it).

> The more I think about it, the more I think a separate "reverse"
> index directory would be a better idea. It just needs to from
> "me" to "who references me", at least so that you can quickly
> find all signatures of a given object. If the reverse directory
> gets wonky, anyone can just delete the reverse index directory
> at any time & reconstruct it by iterating the objects.
> Before "-----BEGIN PGP SIGNATURE-----" you should add:
> signatureof HASHVALUE
> to make reconstruction easy; PGP processors ignore stuff
> before "-----".

Oof, dont do this:

- makes assumptions about the format of the signature
	- that it is ASCII
	- that you can change it

Just add a git header which is independent of the signature data.

In lieu of the 'signature object as precursor' approach above, just 
have the tools maintain an index. It can be maintained as objects as 
added, and can always be blown away and recreated by inspection of 
the repository data.

regards,
--
Paul Jakma	paul@xxxxxxxx	paul@xxxxxxxxx	Key ID: 64A2FF6A
Fortune:
To doubt everything or to believe everything are two equally convenient
solutions; both dispense with the necessity of reflection.
		-- H. Poincar'e
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/