Messages in this thread |  | | | Date | Sun, 24 Apr 2005 19:44:16 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: Git-commits mailing list feed. |
| |
On Mon, 25 Apr 2005, Fabian Franz wrote: > > What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?
Well, the SHA1 of an object really is not a very good name, unless you have something to manage it with. Again, the object database has something to manage and find those objects with - things like .git/HEAD, but also "fsck" to find dangling and unnamed objects.
Maybe we'll never have so many tags that we need to manage them, and yes, if so, we can just have ".git/signatures" be a directory with objects that are just named for their content SHA1, the same way the object database is, but separately (and probably just using a flat file structure, no need for the subdirectory fan-out that the object directory has).
No need for a ".sig" thing, since they'd be defined to be signatures just from their location.
> Or would this violate the concept of the object database to just contain > hashes?
This wouldn't be an object at all in that case, they'd be totally outside the scope of the git object model.
And yes, if they were to be git objects, they'd follow totally different rules: they'd have to have the "tag+length+'\0'" format, and they would be zlib-compressed.
If they are totally outside of git, then I don't care what the object format is, and then it could be just a regular text-file with a signature and content, and just happen to be named for the SHA1 hash so that there is no confusion about what happens when multiple people happen to create different tags with the same name. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |