On Mon, Aug 26, 2013 at 1:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> If your justification were "above says 'there may be a readon why
>> the user wanted to ask it in that way', i.e. 'find in this tree
>> object HEAD:some/path and report where hits appear', but the reason
>> can only be from laziness and/or broken script and the user always
>> wants the answer from within the top-level tree-ish", then that
>> argument may make some sense. You need to justify why it is OK to
>> lose information in the answer by rewriting the colon that separates
>> the question ("in this tree object") and the answer ("at this path
>> relative to the tree object given").
>>
>> Whether you rewrite the input or the output is not important; you
>> are trying to give an answer to a different question, which is what
>> I find questionable.
>
> For example, one of the cases the proposed change will break that I
> am worried about is a script that wants to take N trees and a
> pattern, and report where in the given trees hits appear, something
> like:
>
> git grep -c -e $pattern "$@" |
> perl -e '
> my @trees = @ARGV;
> my %found = ();
> while (<>) {
> my $line = $_;
> for (@trees) {
> my $tree_prefix = $_ . ":";
> my $len = len($tree_prefix);
> if (substr($line, 0, $len) eq $tree_prefix) {
> my ($path_count) = substr($line, $len);
> my ($path, $count) = $path_count =~ /^(.*):(\d+)$/
> $found{$tree} = [$path, $count];
> }
> }
> }
> # Do stats on %found
> ' "$@"
>
I do understand there is potential breakage when a script is parsing
the output. I did not consider that this was a feature someone may
want; it really only looks like a breakage to me, for the reasons I've
already given.
It's surprising just how broken it looks to me (given that I now know
it is not) since all the other filenames output from 'git-grep -l' are
valid filenames or object references. There is only this one
tree-path instance which does not. I suppose I will learn to live
with it.
--
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