David Barr wrote: > The output uses the same format as "git cat-file --batch". This means: <sha1> SP <type> SP <size> LF <contents> LF where <contents> are the raw content of the object in question. If a person just wants to read the <sha1>, the <contents> are wasted computation and I/O. Does that matter? Suppose some day fast-import gains a feature to respond to requests out of order. The response would need to include the name of the object as requested for the frontend to make any sense of it. Would it be worth preparing the format for that now, so the same frontend code can deal with the format produced by fast-import with and without that feature? The format of tags, trees, and commits (though not blobs) is specific to git: fast-import backends for other version control systems would not be able to respond in the same way. So maybe it would make sense to restrict cat requests to blobs for now. > Objects can be specified by path within a tree as well, using a > > cat TREE "PATH" > > syntax. With this syntax, also, the tree can only be specified by > :n marker or 40-digit tree id. I would prefer cat "<path>" within commit commands, which would spit out the content at that path in the currently-staged version of the commit, and a separate C <tree> "<path>" "<path>" to copy data from previous commits. So cat <tree> "<path>" would be replaced with C <tree> "<path>" "dest" cat "dest" when using content from tree:path to prepare dest. Of course, that would be less flexible, but I find it more intuitive for svn-fe at least, perhaps because it fits better with svn's object model. In either regime, I hear there is some demand for allowing commits to be used in place of trees. At any rate, that is not needed for the current version of svn-fe, is it? So maybe it would make sense to strip down the patch to just allow cat <blob> Thanks for resending it. -- 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