[ANNOUNCE] git related v0.3

[ANNOUNCE] git related v0.3

[Felipe Contreras]

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

-- 
Felipe Contreras

Re: [ANNOUNCE] git related v0.3

[Ævar Arnfjörð Bjarmason]

On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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.

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.

Re: [ANNOUNCE] git related v0.3

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > 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.
> 
> 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

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.

-- 
Felipe Contreras

Re: [ANNOUNCE] git related v0.3

[Felipe Contreras]

Ævar Arnfjörð Bjarmason 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

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

  git who -S'<substr>'

Cheers.

-- 
Felipe Contreras