git-who

Once upon a someone asked about seeing who had touched some files. Petr Baudis responded with a quickie script that did the job. I've since expanded upon it a little, and since I find it pretty useful, I figured I'd send it back for others to use too.

As is it's probably not worth including in git, but I'm thinking that someone else can probably come up with some improvements, such as dates in the verbose mode, support for a treeish instead of a single file path, and / or rewriting it in C so that it can work on Windows.

http://github.com/masukomi/git_accessories/tree/master git://github.com/masukomi/git_accessories.git

Not that it's particularly worthy of it's own repo at the moment, but I figure I'll continue to keep poking it from time to time...

-masukomi

On Tue, Oct 07, 2008 at 05:02:46PM -0400, "Rhodes, Kate" <masukomi@gmail.com> wrote:

I thought - based on this - that it's written in ruby or something, but it's just shell and perl, so probably it works in Windows as well without any kind of rewrite.

On Tue, Oct 07, 2008 at 05:02:46PM -0400, Kate Rhodes wrote:

Scripts like this often find a good home in git's contrib/ directory. Consider submitting a patch which adds it there.

I took a look. My biggest complaint is that for many files, it produces too many names. It would be nice to at least sort the names by number of commits. But even more accurate might be the number of added lines. Somebody who creates a 200-line file should surely come before somebody who made a 1-line tweak, right?

But perhaps even more accurate would be to rely on blame output, since it attributes not just added lines, but lines which have actually survived into the current product. And fortunately that is relatively easy to do (only lightly tested):

-- >8 -- #!/usr/bin/perl # # Invoke as 'git who -M -C file.c' (or whichever blame options # you prefer). You can even check a particular set of lines # with "git who -M -C -L 40,60 file.c".

use strict;

open(my $in, '-|', qw(git blame -p), @ARGV);

my %count;
my %author;
my $current_sha1;
while(<$in>) {
  if (!$current_sha1) {
    /^[0-9a-f]{40}/ or die "expected sha1, got $_";
    $current_sha1 = $&;
    $count{$current_sha1}++;
  }
  elsif (/^author (.*)/) {
    $author{$current_sha1} = $1;
  }
  elsif (/^\t/) {
    $current_sha1 = undef;
  }
}

my %acount;
while(my ($h, $c) = each %count) {
  $acount{$author{$h}} += $c;
}

foreach (sort { $acount{$b} <=> $acount{$a} } keys %acount) {
  print "$_ ($acount{$_})\n";
}

On Oct 7, 2008, at 10:25 PM, Jeff King wrote:

Yeah, I agree, I just haven't come up with a better idea that addresses the question of "who touched this". Maybe some sort of recency toggle.

Yeah, I've considered maybe adding a -n (number) like that and ordering people by number of commits. I'm not convinced that, in most cases, size of changes is as important as number. I think it depends on the file. In some cases a person who's constantly mucking about with the file is a better go-to person when you have questions / issues, than someone who happened to make a few large commits a while ago. But then again....

mmm good idea.

excellent! Thank you. I'll poke at this tomorrow. :)

-masukomi

Rhodes, Kate schrieb:

Wouldn't

   git shortlog -s -- path/to/file

solve your problem?

-- Hannes

No. No, that's far too simple.

;)

-Kate

On Oct 8, 2008, at 2:13 AM, Johannes Sixt wrote:

On Wed, 8 Oct 2008, Johannes Sixt wrote:

I suspect "-sn" is better. It sorts by number rather than by name, and if you're interested in who has touched a file, you probably wants to know who has touched it _most_.

And as usual, the nice thing about it is that all the normal git rules apply, so you can do it by multiple files or subdirectories, and you can filter by time. And ignore merges, since they tend to be about upper-level maintainers than about the people doing patches.

So for the kernel, you can do something like

	git shortlog -ns --no-merges --since=6.months.ago drivers/scsi include/scsi

and see who has been doing scsi-related stuff lately.

Of course, when it comes to relevance, it may be more interesting to just look at 'git blame' output, and then you're limited to single files at a time. And performance is going to be a problem, especially if you enable movement detection.

But we don't have anything special for that. You can do it with something like

	git blame -M -w kernel/sched.c |
		grep -v '^^' |
		cut -d'(' -f2- |
		cut -c1-20 |
		sort |
		uniq -c |
		sort -n

which will ignore the root commit (so as not to give me all the credit for old history), but it would probably be better (but more complex - need perl or some other "real" language with associative arrays etc to remember the commit information) to parse the output of "git blame --incremental" instead.

		Linus