Jakub Narebski wrote: > I wonder if it makes sense to be able to add tag objects instead > of commit objects to trees (depeel to tree or blob)... > I'd say "as well as", and the semantics should be that to something browsing the filesystem, a tag looks like the type of object it refers to. eg, tag a tree, it's a tree, tag a commit, it's a sub-project/tree, tag a blob, it's a file. The use case I'm thinking of is semi-transparent storing of archives; instead of storing the archive body, store a tag which contains the "extra" information - like the gzip headers for a gz and which compression options are needed to reproduce the same output stream. For a tar, the per-file information such as the filestamps, owner and permissions are recorded, and it points to a tree. A clever porcelain could detect these file types, and make sure the uncompressed streams are stored. People who are using clients which don't understand these tag objects in between will get the contents of the node checked out instead, so instead of getting "foo.tar.gz" as a file, I got a "foo.tar.gz/" directory. Sam. - 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