I recently had a situation where I was using git cat-file (--batch) to read files and directories out of the repository -- basically, todo the equivalent of open, opendir, etc, on an arbitrary revision. Unfortunately, I had to do a lot of gymnastics to handle symlinks in the repository. Instead of just doing echo $SHA:foo/bar/baz | git cat-file --batch, I would have to first check if foo was a symlink, and if so, follow it, and then check bar, and so on. Instead, it would be cool if cat-file had a mode in which it would follow symlinks. The major wrinkle is that symlinks can point outside the repository -- either because they are absolute paths, or because they are relative paths with enough ../ in them. For this case, I propose that --follow-symlinks should output [sha] "symlink" [target] instead of the usual [sha] "blob" [bytes]. Since --follow-symlinks is new, this format change will not break any existing code. (I also propose that we use Linux's limit of 40 symlinks by default, but --follow-symlinks could also have =max_links_to_follow to adjust this if anyone cares) Do people think this is reasonable? If so, I'll see if I can get some time to work on it this month. -- 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