Re: [ANNOUNCE] git related v0.3
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
Æ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
[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 gits...@pobox.com (signer: 90%, author: 5%) Felipe Contreras felipe.contre...@gmail.com (author: 25%, reviewer: 2%) Sverre Rabbelier srabbel...@gmail.com (author: 17%, acker: 2%, signer: 7%) Jeff King p...@peff.net (acker: 17%, author: 10%) Shawn O. Pearce spea...@spearce.org (author: 5%, signer: 2%, cced: 2%) Elijah Newren new...@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 -- 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
