Junio C Hamano schrieb: > So to recap: > > - "git-archive-tree --format <foo> <foo specific options> <tree>" > would know how to create <foo> format archive and send the result to > stdout. > > - "git-download-archive <repo> <git-archive-tree-command-line>" would > talk with "git-upload-archive" in the remote repository, give > archive-tree command line to it and receives the result. > > - "git-upload-archive <repo>" is not used by the end user. Underlying > git-archive-tree command line options are sent over the protocol from > download-archive, just like upload-tar does. > > If this is what you mean, I think three of us are in agreement here. Well, this is just _one_ of the positions I've taken on this topic, I have to admit. Franck then convinced me that merging downloader and archiver into one command is nice for users (less commands to remember, keeps existing --remote option) even if it doesn't make sense technically, because their implementations have nothing in common. This is a bikeshed colour discussion, and I'm bad at it. I'll shut up on this and simply follow the directions above. >> My next steps will be to make traverse_tree() support path specs, >> in order to achieve feature parity with read_tree_recursive(). I >> hope that the former keeps being significantly faster than the >> latter even after that. > > A thing that have been bothering me for some time in pathspec area is > that we have two (eh perhaps three) quite different pathspec > semantics. > > - diff-tree family (and anything based on revision.c including > git-log) is a strict prefix directory match (e.g. no wildcards, and > "Documentation/howto" matches the directory but not > "Documentation/howto-index.sh") > > - ls-files family (ls-files used to be an one odd man out, but > git-grep mimics it, and "git-commit <paths>" uses ls-files internally > so they form a family) is prefix match with fnmatch match upon > wildcard (e.g. "Documentation/howto" still matches the directory but > not "Documentation/howto-index.sh", but you can say > "Documentation/howto*" to match both, and you can even say > "Document*"). > > The former semantics is very friendly with "struct tree_desc" based > traversal. Allowing pathspecs with ls-files style matching would > probably more useful but more work. And there are at least four > implementations of pathspec matcher with slightly different > interfaces (ugh, sorry) if I am not mistaken: builtin-ls-files.c has > one (match), tree-diff.c has another (interesting), builtin-grep.c > has one (pathspec_matches), dir.c has another (match_pathspec). > > We might be able to share code with para-walk.c in "pu" (it is > designed to walk zero or more trees optionally with index and working > tree in parallel and we would be using it to walk only single tree > without index nor working tree). That would give me an incentive to > clean up the code ;-) Currently it is a ten "WIP" patch series. > > One thing it attempts to do on the side is to consolidate the > diff-tree style ones into one by introducing another in read-cache.c > (pathname_included) but it does not convert existing users of other > matchers to use it yet. Interesting. OK, I'll check out the existing implementations with an eye on consolidation and also take a look around that scary place named 'pu'. ;-) So far I have failed in creating a traverse_tree() function with path spec match support which also is faster than read_tree_recursive(). Maybe the speed difference between 'git-tar-tree' and 'git-archive-tree -ftar' is caused by something else. I keep on trying. René - 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