From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 27 Aug 2013 04:07:33 GMT
Subject: Re: [RFC/PATCH] Fix path prefixing in grep_object
Message-ID: <xmqqhaebhj3u.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqbo4kicsm.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

> Not necessarily.  If the user is asking the question in a more
> natural way (I want to see where in 'next' branch's tip commit hits
> appear, by the way, I know I am only interested in builtin/ so I'd
> give pathspec as well when I am asking this question), the output
> does give <commit> <colon> <path>, so it is more than coincidence.

This part needs to be qualified.  "Natural" is of course in the eyes
of beholder.  If we assume that your #1 holds true (i.e. the tuple
<in which tree object are we reporting, what path we saw hits> is
important and merging them into one <in what blob we saw hits> lose
information), then it is natural to ask "inside origin/master tree,
where do I have hits?  By the way, I am only interested in builtin/"
and get "origin/master:builtin/pack-objects.c" as an answer (this is
from your earlier example), than asking "inside origin/master:builtin
tree, where do I have hits?"

If we do not consider #1 is false and the tree information can be
discarded, then it does not matter if we converted the colon after
origin/master to slash when we answer the latter question, and the
latter question stops being unnatural.

> ...
> but it might be a good change to allow A:B:C to be parsed as a
> proper extended SHA-1 expression and make it yield
>
> 	git rev-parse $(git rev-parse $(git rev-parse A):B):C
>
> Right now, "B:C" is used as a path inside tree-ish "A", but I think
> we can safely fall back, when path B:C does not appear in tree-ish
> A, to see if path B appears in it and is a tree, and then turn it
> into a look-up of path C in that tree A:B.

And if we want to keep the <tree, path> tuple, but still want to
make it easier to work with the output, allowing A:B:C to be parsed
as an extended SHA-1 expression would be a reasonable solution, not
a work-around. The answer is given to the question asked in either
way (either "in origin/master, but limited to these pathspecs" or
"in the tree origin/master:builtin/") without losing information,
but the issue you had is that the answer to the latter form of
question is not understood by the object name parser, which I
personally think is a bug.