{"thread":{"id":"36693","subject":"[ANNOUNCE] git related v0.3","startedAt":"2014-05-19T00:36:51Z","lastAt":"2021-05-27T00:58:10Z","messageCount":4,"participants":["Felipe Contreras","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"242136","messageId":"537952234b691_10da88d308d8@nysa.notmuch","threadId":"36693","inReplyTo":null,"subject":"[ANNOUNCE] git related v0.3","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-19T00:36:51Z","receivedAt":"2014-05-19T00:36:51Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nThis tool finds people that might be interested in a patch, by going\nback through the history for each single hunk modified, and finding\npeople that reviewed, acknowledged, signed, or authored the code the\npatch is modifying.\n\nIt does this by running `git blame` incrementally on each hunk, and\nfinding the relevant commit message. After gathering all the relevant\npeople, it groups them to show what exactly was their role when the\nparticipated in the development of the relevant commit, and on how many\nrelevant commits they participated. They are only displayed if they pass\na minimum threshold of participation.\n\nIt is similar the the `git contacts` tool in the contrib area, which is a\nrewrite of this tool, except that `git contacts` does the absolute minimum;\n`git related` is way superior in every way.\n\nFor example:\n\n------------\n% git related master..fc/transport/improv\n Junio C Hamano (signer: 90%, author: 5%)\n Felipe Contreras (author: 25%, reviewer: 2%)\n Sverre Rabbelier (author: 17%, acker: 2%, signer: 7%)\n Jeff King (acker: 17%, author: 10%)\n Shawn O. Pearce (author: 5%, signer: 2%, cced: 2%)\n Elijah Newren (author: 10%)\n------------\n\nIn addition, it has an option to output the list of commits, instead of the\ncontributors, which allows you to easily find out the previous changes to the\nlines your patches modify.\n\n------------\n% git related -c master..fc/transport/improv\n 99d9ec0 Merge branch 'fc/transport-helper-no-refspec'\n 67c9c78 transport-helper: barf when user tries old:new\n 0460ed2 documentation: trivial style cleanups\n 126aac5 transport-helper: fix remote helper namespace regression\n 21610d8 transport-helper: clarify pushing without refspecs\n a93b4a0 transport-helper: warn when refspec is not used\n 664059f transport-helper: update remote helper namespace\n c4458ec fast-export: Allow pruned-references in mark file\n ...\n------------\n\nMoreover, when sending patches for review, you can configure `git send-email`\nto use `git related` to find relevant people that should be Cc'ed:\n\n------------\n% git send-email --cc-cmd='git related' *.patch\n------------\n\nCompared to `git related`, `git contacts` has the following limitations:\n\n 1) Doesn't show the amount of involvement\n 2) Doesn't show the kind of involvement (reviewer, author) nor\n does it group people by their email address\n 3) Doesn't have the option to show the commit themselves\n 4) Doesn't have any options at all (--since, --min-percent)\n\nCheers.\n\nhttps://github.com/felipec/git-related\n\nChanges since v0.1:\n\n * Fix compatibility with older versions\n * Add -clong option\n * Add manpage\n * Improve performance by grouping line ranges\n\nFelipe Contreras (12):\n Fix compatibility with Ruby 1.9\n Add support for Ruby 1.8\n Fix popen workaround\n Refactor blame parsing\n Pass multiple ranges to `git blame`\n test: add gitingnore file\n Add -clong option\n Add manpage\n build: add installation stuff\n readme: trivial updates\n test: add test-lib helper\n travis: initial configuration\n\n-- \nFelipe Contreras\n"},{"id":"242154","messageId":"CACBZZX6gOeTrLJwL-Zp5hEEbWCipioPgNKt7Tc41ixcQLQshiw@mail.gmail.com","threadId":"36693","inReplyTo":"537952234b691_10da88d308d8@nysa.notmuch","subject":"Re: [ANNOUNCE] git related v0.3","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2014-05-19T10:11:07Z","receivedAt":"2014-05-19T10:11:07Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras\n wrote:\n> This tool finds people that might be interested in a patch, by going\n> back through the history for each single hunk modified, and finding\n> people that reviewed, acknowledged, signed, or authored the code the\n> patch is modifying.\n>\n> It does this by running `git blame` incrementally on each hunk, and\n> finding the relevant commit message. After gathering all the relevant\n> people, it groups them to show what exactly was their role when the\n> participated in the development of the relevant commit, and on how many\n> relevant commits they participated. They are only displayed if they pass\n> a minimum threshold of participation.\n>\n> It is similar the the `git contacts` tool in the contrib area, which is a\n> rewrite of this tool, except that `git contacts` does the absolute minimum;\n> `git related` is way superior in every way.\n\nThe general heuristic I use, which I've found to be much better than\ngit-blame is:\n\n 1. Find substrings of code I'm directly removing/altering, and\nfunctions I'm removing/altering\n 2. Do git log --reverse -p -S'' (maybe with -- file) for a\nlist of substrings\n\nI've generally found that to be a better heuristic to start with in\nboth git.git and non-git.git code, blame tends to bias the view\ntowards giving you people who've just moved the code around or made\nminor changes (are you at least using blame -w?).\n\nWe recently discussed having a tool like this at work to aid in our\nreview process, but I pointed out there that you had to be careful\nwith how it was written, e.g. if you rank importance as a function of\nthe number of commits you're now going to bother people more with\nreview requests if they make granular commits, whereas what you\nactually want is to contact the \"significant\" authors, which generally\nspeaking can be defined as the original authors of the code you're\naltering or replacing.\n"},{"id":"242208","messageId":"537a7725558c1_afee5d30095@nysa.notmuch","threadId":"36693","inReplyTo":"CACBZZX6gOeTrLJwL-Zp5hEEbWCipioPgNKt7Tc41ixcQLQshiw@mail.gmail.com","subject":"Re: [ANNOUNCE] git related v0.3","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-19T21:27:01Z","receivedAt":"2014-05-19T21:27:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras\n> wrote:\n> > This tool finds people that might be interested in a patch, by going\n> > back through the history for each single hunk modified, and finding\n> > people that reviewed, acknowledged, signed, or authored the code the\n> > patch is modifying.\n> >\n> > It does this by running `git blame` incrementally on each hunk, and\n> > finding the relevant commit message. After gathering all the relevant\n> > people, it groups them to show what exactly was their role when the\n> > participated in the development of the relevant commit, and on how many\n> > relevant commits they participated. They are only displayed if they pass\n> > a minimum threshold of participation.\n> >\n> > It is similar the the `git contacts` tool in the contrib area, which is a\n> > rewrite of this tool, except that `git contacts` does the absolute minimum;\n> > `git related` is way superior in every way.\n> \n> The general heuristic I use, which I've found to be much better than\n> git-blame is:\n> \n> 1. Find substrings of code I'm directly removing/altering, and\n> functions I'm removing/altering\n> 2. Do git log --reverse -p -S'' (maybe with -- file) for a\n> list of substrings\n\nYes, that is true, but it cannot be automated. When I'm lazy I just do\n`git related -cfull a..b`, which will show me the full patches so I can\ndecide if they are relevant or not.\n\nOne possibility would be to add an additional --keywords option to `git\nrelated`. Another would be to add an --interactive where each supposedly\nrelevant patch is shown for the user to decide if it truly is.\n\n-- \nFelipe Contreras"},{"id":"425642","messageId":"60aeee9a14f13_770c208cd@natae.notmuch","threadId":"36693","inReplyTo":"CACBZZX6gOeTrLJwL-Zp5hEEbWCipioPgNKt7Tc41ixcQLQshiw@mail.gmail.com","subject":"Re: [ANNOUNCE] git related v0.3","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-27T00:58:02Z","receivedAt":"2021-05-27T00:58:10Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> The general heuristic I use, which I've found to be much better than\n> git-blame is:\n> \n> 1. Find substrings of code I'm directly removing/altering, and\n> functions I'm removing/altering\n> 2. Do git log --reverse -p -S'' (maybe with -- file) for a\n> list of substrings\n\nv1.0 of git-related has a similar tool: git-who, which you can use to do\nprecisely that:\n\n git who -S''\n\nCheers.\n\n-- \nFelipe Contreras"}]}