Æ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.
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