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

[Junio C Hamano <junkio@cox.net>]

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.