Re: [PATCH 2/2] Teach name-rev to identify revisions containing a certain blob

Having said what I said in the comments on [PATCH 1/2], I think you are either solving a wrong problem, or even if you are solving the right problem, you are solving in a wrong way in this patch.

I do not think Mike wants a way to deal with what he gets in his mailbox from an end user who did this:

	$ cat a-file-whose-name-was-not-told-to-mike >junk
	$ mailx mike.coleman <junk

It's more like he learns the contents _and_ the path from an end-user who is having trouble with a tarball of unknown vintage, and wants to identify which snapshot had that contents at that path [*1*].

So I do not think it is solving the right problem to run around all over the tree without knowing the path, looking for a particular object name. It certainly makes the solution much more expensive.

Even if that were Mike's problem, there is a problem that the same object can appear at different places in different trees. Keeping a single pathname registered in object_hash would mean the answer is "whatever happens to be found first", regardless of the path.

To make "whatever happens to be found first" semantics useful, I think you would need to make the traversal more controllable by the user of name-rev. For example, Mike may know what he gave the end user was from maintenance series of 1.4.4 software, in which case you would want to let him say "traverse from the tip of 1.4.4 maintenance branch down, do not worry about other branches such as 1.5.0 series or 1.4.3 maintenance series".

Your earlier --ref-filter patch would certainly help it, but a solution based on grep over "rev-list | ls-tree --stdin" (which currently does not exist) might be more appropriate and flexible? I dunno.

[Footnote]

*1* To find a revision that had a particular object at a known path, you should be able to do:

	git rev-list <starting refs> |
        git diff-tree --stdin --raw -r -Z |
	grep -z that-object-name

but an earlier commit abd4e222 needs to be further enhanced to add -Z option that means "output fields are not NUL terminated, output records are", which did not happen.