git-who

git-who

[Rhodes, Kate]

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

Re: git-who

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

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

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git-who

[Jeff King]

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

> 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.

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

> git://github.com/masukomi/git_accessories.git

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";
}

Re: git-who

[Rhodes, Kate]

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

> On Tue, Oct 07, 2008 at 05:02:46PM -0400, Kate Rhodes wrote:
>
>> 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.
>
> Scripts like this often find a good home in git's contrib/ directory.
> Consider submitting a patch which adds it there.
>
>> git://github.com/masukomi/git_accessories.git
>
> I took a look. My biggest complaint is that for many files, it  
> produces
> too many names.

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.

> 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?

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....


>
> 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.

mmm good idea.


> And fortunately that is relatively
> easy to do (only lightly tested):

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

-masukomi

>
>
> -- >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";
> }

Re: git-who

[Johannes Sixt]

Rhodes, Kate schrieb:
> Once upon a someone asked about seeing who had touched some files. Petr
> Baudis responded with a quickie script that did the job.

Wouldn't

   git shortlog -s -- path/to/file

solve your problem?

-- Hannes

Re: git-who

[Rhodes, Kate]

No. No, that's far too simple.


;)

-Kate

On Oct 8, 2008, at 2:13 AM, Johannes Sixt wrote:
> Rhodes, Kate schrieb:
>> Once upon a someone asked about seeing who had touched some files.  
>> Petr
>> Baudis responded with a quickie script that did the job.
>
> Wouldn't
>
>   git shortlog -s -- path/to/file
>
> solve your problem?
>
> -- Hannes
>

Re: git-who

[Linus Torvalds]

On Wed, 8 Oct 2008, Johannes Sixt wrote:
> 
> Wouldn't
> 
>    git shortlog -s -- path/to/file

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