On Thu, 19 Jan 2006, Johannes Schindelin wrote:
quoted text
> 
> it is a fact that I'm stupid, but in this case it might be a bug, too. 
> When I call
> 
> 	git-whatchanged -Sget_remote_heads 1baaae5e fetch-pack.c
> 
> the first shown commit is d1c133f5. However, if I substitute the 
> "-Sget_remote_heads" by "-p" I see that the diff of commit 1baaae5e *does* 
> change a line containing that text.
> 
> What am I doing wrong?

Nothing. But pickaxe really has very strange semantics, which imho makes 
it much less useful than it could be.

What pickaxe ends up doing is to literally see if the original has that 
string, and the result does not. I think it _counts_ the number of 
occurrences of a string in the before/after situation, and if the count 
differs, it's considered interesting.

So yes, there's a commit that has "get_remote_heads" as part of the 
change, but that particular string did not actually change in that commit: 
_other_ stuff on the same line did change. That particular string existed 
both before and after.

So when you use pickaxe, you really want to match the whole line you're 
looking for - otherwise you'll only see when people add or remove a 
particular string, not when they change things around it. Even then, if 
that particular line gets _moved_ (but otherwise is unchanged) pickaxe 
won't pick it up.

So you could have done a more exact search:

    git-whatchanged -p \
	-S"get_remote_heads(fd[0], &ref, nr_match, match, 1);" \
	1baaae5e fetch-pack.c

would have found where that particular line was introduced (and deleted).

Me, I find the pickaxe semantics so non-intuitive that I never use it 
(that said, the counting begaviour is better than what it _used_ to be, 
which, if I recall correctly, was just "it existed before, doesn't exist 
now").

I at one point suggested to Junio that the semantics be something else 
("mark the source and destination within 'x' characters of an occurrence 
of that string, and then if the _delta_ touches any of the marked areas, 
consider it to be a hit") but I think the problem was simply that it's 
more complex. You have to look at the ranges that the delta actually 
touches, which is more work than just looking at the original and final 
file contents themselves.

I suspect (but can't speak for him, obviously) that Junio would be open to 
more friendly pickaxe semantics if the suggested semantics change was 
accompanied by an actual diff to implement them.

In the meantime, you really need to think carefully about what you're 
doing when you use "-S". 

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html