Ævar Arnfjörð Bjarmason wrote: > On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html