Check in a little toy that graphs history of words in the source.

Check in a little toy that graphs history of words in the source.

Useful for tracking progress on projects like wstring removal.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=55107

[Evan Martin, 2010-08-05 15:16:37]

Not ready for review yet, need to merge in the change from
http://gist.github.com/509508

[Nico, 2010-08-05 16:17:26]

The following is just a suggestion:

http://codereview.chromium.org/3017058/diff/2001/3002
File tools/git/graph.sh (right):

http://codereview.chromium.org/3017058/diff/2001/3002#newcode37
tools/git/graph.sh:37: EOF
Would it be cuter to output an html file that shows the graph using e.g. what
view-source:http://build.chromium.org/buildbot/waterfall/stats/Chromium%20XP
uses? That'd remove the R dependency.

[Evan Martin, 2010-08-05 18:01:05]

I tried Bernhard's idea but noticed it's a lot slower:
1m18s to do the checkout-then grep, while 2m to do the grep-with-tree.
I think this is because each checkout is near the others in time so there are
fewer on-disk files to change, while the grep-with-tree needs to re-fetch the
files with each grep.

It would be cute to generate an HTML graph, but that means I don't get an image
I can paste into buzz etc. and I don't have time to fiddle with it right now. 
I'd accept a patch.  :)

I believe this is ready for review now.

[Nico, 2010-08-05 18:11:53]

LG, some incoherent rambling below.

http://codereview.chromium.org/3017058/diff/7001/8002
File tools/git/graph.sh (right):

http://codereview.chromium.org/3017058/diff/7001/8002#newcode25
tools/git/graph.sh:25: for ago in $(seq 90 -1 0); do
`for ago in {90..0}; do` instead?

http://codereview.chromium.org/3017058/diff/7001/8002#newcode33
tools/git/graph.sh:33: R CMD BATCH <(cat <<EOF
Neat, I wasn't actively aware that <() evaluates to a filename.

http://codereview.chromium.org/3017058/diff/7001/8002#newcode42
tools/git/graph.sh:42: rm -f $datafile
do you want a trap for this? if not, maybe a comment that says "this is simple
enough that we don't bother with a trap for clean up"?

[Bernhard Bauer, 2010-08-05 22:55:05]

Hm, I thought that the reason that git-grep is faster than regular
grep is exactly that it does not need to look at the files in the
working tree, but can just read from its store?

On Thursday, August 5, 2010,  <evan@chromium.org> wrote:
> I tried Bernhard's idea but noticed it's a lot slower:
> 1m18s to do the checkout-then grep, while 2m to do the grep-with-tree.
> I think this is because each checkout is near the others in time so there are
> fewer on-disk files to change, while the grep-with-tree needs to re-fetch the
> files with each grep.
>
> It would be cute to generate an HTML graph, but that means I don't get an
image
> I can paste into buzz etc. and I don't have time to fiddle with it right now.
> I'd accept a patch.  :)
>
> I believe this is ready for review now.
>
> http://codereview.chromium.org/3017058/show
>

[Evan Martin, 2010-08-05 22:59:19]

I think it's mostly because it only looks at the filenames you specify.

Even git grep knows to shell out to grep because you can't beat grep:
http://ridiculousfish.com/blog/archives/2006/05/30/old-age-and-treachery/

On Thu, Aug 5, 2010 at 3:54 PM, Bernhard Bauer <bauerb@chromium.org> wrote:
> Hm, I thought that the reason that git-grep is faster than regular
> grep is exactly that it does not need to look at the files in the
> working tree, but can just read from its store?
>
> On Thursday, August 5, 2010,  <evan@chromium.org> wrote:
>> I tried Bernhard's idea but noticed it's a lot slower:
>> 1m18s to do the checkout-then grep, while 2m to do the grep-with-tree.
>> I think this is because each checkout is near the others in time so there are
>> fewer on-disk files to change, while the grep-with-tree needs to re-fetch the
>> files with each grep.
>>
>> It would be cute to generate an HTML graph, but that means I don't get an
image
>> I can paste into buzz etc. and I don't have time to fiddle with it right now.
>> I'd accept a patch.  :)
>>
>> I believe this is ready for review now.
>>
>> http://codereview.chromium.org/3017058/show
>>
>