# git-who 7 messages from 2008-10-07 to 2008-10-08. Participants: Rhodes, Kate, Miklos Vajna, Jeff King, Johannes Sixt, Linus Torvalds. Thread: https://gitlist.dev/t/15816 ## Rhodes, Kate, 2008-10-07 21:02 Subject: git-who Message-ID: URL: https://gitlist.dev/e/DE2CF127-A7FD-4765-A8E4-5235C5F1B9A9%40gmail.com ``` 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 ``` ## Miklos Vajna, 2008-10-07 22:35 Subject: Re: git-who Message-ID: <20081007223530.GF536@genesis.frugalware.org> URL: https://gitlist.dev/e/20081007223530.GF536%40genesis.frugalware.org In-Reply-To: ``` On Tue, Oct 07, 2008 at 05:02:46PM -0400, "Rhodes, Kate" 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. ``` ## Jeff King, 2008-10-08 02:25 Subject: Re: git-who Message-ID: <20081008022505.GB29313@coredump.intra.peff.net> URL: https://gitlist.dev/e/20081008022505.GB29313%40coredump.intra.peff.net In-Reply-To: ``` 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"; } ``` ## Rhodes, Kate, 2008-10-08 04:59 Subject: Re: git-who Message-ID: <70ED45EF-54B8-42D9-98BA-F2E98C786419@gmail.com> URL: https://gitlist.dev/e/70ED45EF-54B8-42D9-98BA-F2E98C786419%40gmail.com In-Reply-To: <20081008022505.GB29313@coredump.intra.peff.net> ``` 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"; > } ``` ## Johannes Sixt, 2008-10-08 06:13 Subject: Re: git-who Message-ID: <48EC4F9D.4020202@viscovery.net> URL: https://gitlist.dev/e/48EC4F9D.4020202%40viscovery.net In-Reply-To: ``` 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 ``` ## Rhodes, Kate, 2008-10-08 13:48 Subject: Re: git-who Message-ID: <8323B5AF-AECC-4576-BA85-382BAD8FE74B@gmail.com> URL: https://gitlist.dev/e/8323B5AF-AECC-4576-BA85-382BAD8FE74B%40gmail.com In-Reply-To: <48EC4F9D.4020202@viscovery.net> ``` 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 > ``` ## Linus Torvalds, 2008-10-08 18:35 Subject: Re: git-who Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810081119490.3208%40nehalem.linux-foundation.org In-Reply-To: <48EC4F9D.4020202@viscovery.net> ``` 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 ```