linux-kernel - Re: whomto.pl -- finding out whom to send patches to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 May 2008 16:33:22 -0700
From:	Junio C Hamano <gitster@...ox.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Sverre Rabbelier <alturin@...il.com>,
	Joe Perches <joe@...ches.com>, git@...r.kernel.org
Subject: Re: whomto.pl -- finding out whom to send patches to

Vegard Nossum <vegard.nossum@...il.com> writes:

> I've written this perl script that takes a patch as input and prints the
> authors/committers of the affected lines, using git-blame as the back end.
>
> (The purpose of this is of course to find out whom to send patches to.)
>
> There are some caveats:
>
> - If I've understood correctly, git-blame incremental output doesn't split
>   commits when a newer one is found, so we currently possibly take into
>   account more than just the last patch to touch a line. This might not be
>   a disadvantage, however...

"git blame" does not give irrelevant commits in its output, with or
without --incremental.  Perhaps you were thinking about the "oops, earlier
one was wrong, here are the corrections" behaviour of "git log
--early-output", which is an unrelated mechanism in a different command.

But I have to wonder why you used --incremental and not --porcelain
format, the latter of which is more compact and is designed for parsing by
tools.

I also have to wonder why you did not use -M, -C, and/or -w, if you used
blame to find the true origin of lines that are involved.

Unless the patch is truly about a narrow region of a handful files
(e.g. micro-optimizing the implementation of a single function without
changing its external interface at all, or fixing an off-by-one error in a
group of functions that do similar things), I suspect that it would make
more sense to use "git shortlog --no-merges -- paths" to get the list of
people who are involved in the general area, even though they may not have
been involved in particular _lines_ that the patch touches.  For example,
if a patch changes the lines in a function's implementation, you would
want input not only from the people who improved the implementation of the
function over the years, but more from the people who care about the
calling sites of that function the patch is touching.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/