Re: [PATCH][RFC] Add git-archive-tree

[Rene Scharfe <rene.scharfe@lsrfire.ath.cx>]

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é