Re: [ANNOUNCE] git related v0.3

2014-05-19 Thread Ævar Arnfjörð Bjarmason
On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
felipe.contre...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git related v0.3

2014-05-19 Thread Felipe Contreras
Ævar Arnfjörð Bjarmason wrote:
 On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
 felipe.contre...@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--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html