[ANNOUNCE] git related v0.3

Hi,

This tool finds people that might be interested in a patch, by going back through the history for each single hunk modified, and finding people that reviewed, acknowledged, signed, or authored the code the patch is modifying.

It does this by running `git blame` incrementally on each hunk, and finding the relevant commit message. After gathering all the relevant people, it groups them to show what exactly was their role when the participated in the development of the relevant commit, and on how many relevant commits they participated. They are only displayed if they pass a minimum threshold of participation.

It is similar the the `git contacts` tool in the contrib area, which is a rewrite of this tool, except that `git contacts` does the absolute minimum; `git related` is way superior in every way.

For example:

------------
% git related master..fc/transport/improv
  Junio C Hamano <gitster@pobox.com> (signer: 90%, author: 5%)
  Felipe Contreras <felipe.contreras@gmail.com> (author: 25%, reviewer: 2%)
  Sverre Rabbelier <srabbelier@gmail.com> (author: 17%, acker: 2%, signer: 7%)
  Jeff King <peff@peff.net> (acker: 17%, author: 10%)
  Shawn O. Pearce <spearce@spearce.org> (author: 5%, signer: 2%, cced: 2%)
  Elijah Newren <newren@gmail.com> (author: 10%)
------------

In addition, it has an option to output the list of commits, instead of the contributors, which allows you to easily find out the previous changes to the lines your patches modify.

------------
% git related -c master..fc/transport/improv
  99d9ec0 Merge branch 'fc/transport-helper-no-refspec'
  67c9c78 transport-helper: barf when user tries old:new
  0460ed2 documentation: trivial style cleanups
  126aac5 transport-helper: fix remote helper namespace regression
  21610d8 transport-helper: clarify pushing without refspecs
  a93b4a0 transport-helper: warn when refspec is not used
  664059f transport-helper: update remote helper namespace
  c4458ec fast-export: Allow pruned-references in mark file
  ...
------------

Moreover, when sending patches for review, you can configure `git send-email` to use `git related` to find relevant people that should be Cc'ed:

------------ % git send-email --cc-cmd='git related' *.patch ------------

Compared to `git related`, `git contacts` has the following limitations:

 1) Doesn't show the amount of involvement
 2) Doesn't show the kind of involvement (reviewer, author) nor
    does it group people by their email address
 3) Doesn't have the option to show the commit themselves
 4) Doesn't have any options at all (--since, --min-percent)

Cheers.

https://github.com/felipec/git-related

Changes since v0.1:

 * Fix compatibility with older versions
 * Add -clong option
 * Add manpage
 * Improve performance by grouping line ranges

Felipe Contreras (12):
      Fix compatibility with Ruby 1.9
      Add support for Ruby 1.8
      Fix popen workaround
      Refactor blame parsing
      Pass multiple ranges to `git blame`
      test: add gitingnore file
      Add -clong option
      Add manpage
      build: add installation stuff
      readme: trivial updates
      test: add test-lib helper
      travis: initial configuration

On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

The general heuristic I use, which I've found to be much better than git-blame is:

 1. Find substrings of code I'm directly removing/altering, and
functions I'm removing/altering
 2. Do git log --reverse -p -S'<substr>' (maybe with -- file) for a
list of substrings

I've generally found that to be a better heuristic to start with in both git.git and non-git.git code, blame tends to bias the view towards giving you people who've just moved the code around or made minor changes (are you at least using blame -w?).

We recently discussed having a tool like this at work to aid in our review process, but I pointed out there that you had to be careful with how it was written, e.g. if you rank importance as a function of the number of commits you're now going to bother people more with review requests if they make granular commits, whereas what you actually want is to contact the "significant" authors, which generally speaking can be defined as the original authors of the code you're altering or replacing.

Ævar Arnfjörð Bjarmason wrote:

Yes, that is true, but it cannot be automated. When I'm lazy I just do `git related -cfull a..b`, which will show me the full patches so I can decide if they are relevant or not.

One possibility would be to add an additional --keywords option to `git related`. Another would be to add an --interactive where each supposedly relevant patch is shown for the user to decide if it truly is.

Ævar Arnfjörð Bjarmason wrote:

v1.0 of git-related has a similar tool: git-who, which you can use to do precisely that:

  git who -S'<substr>'

Cheers.