> Patches are welcome. I'd be happy to patch git-contacts to link to the message you just sent, then maybe someone more qualified would know where to start... :) Frederick On Fri, Sep 21, 2018 at 01:18:30AM -0400, Eric Sunshine wrote: > On Wed, Sep 19, 2018 at 6:49 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Frederick Eaton <frederik@xxxxxxx> writes: > > > By the way for some reason git-contacts shows more names when I run it > > > on the patch hash than when I give it the patch name: > > > > > > $ ./contrib/contacts/git-contacts 222580cb60ee64f7b81fed64ec8fbfc81952557f > > > Sébastien Guimmara <sebastien.guimmara@xxxxxxxxx> > > > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> > > > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> > > > Junio C Hamano <gitster@xxxxxxxxx> > > > $ ./contrib/contacts/git-contacts ./outgoing/0002-git-column.1-clarify-initial-description-provide-exa.patch > > > Junio C Hamano <gitster@xxxxxxxxx> > > > > I've never trusted what git-contacts say, but the latter one > > certainly looks strange [...] > > I don't use git-contacts, but the first invocation isn't consulting > just a single commit but rather a range of commits. From git-contacts > documentation: > > Input consists of one or more patch files or revision arguments. > A revision argument can be a range or a single `<rev>` which is > interpreted as `<rev>..HEAD`, thus the same revision arguments > are accepted as for linkgit:git-format-patch[1]. Patch files and > revision arguments can be combined in the same invocation. > > So, you are actually running git-contacts on the range 222580cb..HEAD, > and 222580cb isn't even one of the patches being consulted (due to how > the range syntax does not include the argument to the left of ".."). > To consult just that one commit, you'd want perhaps: > > git-contacts 222580cb^..222580cb > > > [...] as, > > > > git log --no-merges Documentation/git-column.txt > > > > makes it clear that I have nothing to do with it ;-). Perhaps the > > tool gives too much credit for Signed-off-by: footer, or something. > > Since git-contacts can be used as git-send-email's --cc-cmd, it can > potentially be invoked many times, and it's a slow command (due to all > the "blaming" via git-blame). As an optimization, git-contacts limits > the timeframe of the blame via git-blame's --since option, with a > hardcoded limit of 5 years. So, the git-blame invocation made by > git-contacts for this patch file is: > > git blame --porcelain -C -L13,+7 -L23,+7 -L43,+6 \ > --since 5-years-ago \ > 4a189fff51b1^ -- Documentation/git-column.txt > > Since the lines changed by the patch have not been touched within that > timeframe, git-blame assigns those lines to boundary commit 128a96c984 > (Update draft release notes to 1.8.5 for the fifth batch of topics, > 2013-09-20), which was authored by Junio, which is why he shows up as > the only "contact". > > If we remove the --since restriction: > > git blame --porcelain -C -L13,+7 -L23,+7 -L43,+6 \ > 4a189fff51b1^ -- Documentation/git-column.txt > > then the lines are correctly "blamed" to Duy via commit 7e29b8254f > (Add column layout skeleton and git-column, 2012-04-21). > > The "Limitations" section of the git-contacts documentation says this: > > Several conditions controlling a person's significance are > currently hard-coded, such as minimum participation level (10%), > blame date-limiting (5 years), and `-C` level for detecting moved > and copied lines (a single `-C`). In the future, these conditions > may become configurable. > > So, this sort of potential issue was understood. Felipe's > git-related[1], from which git-contacts arose, eventually grew the > ability to tweak these hard-coded values via command-line options. The > same could be done for git-contacts. Patches are welcome. > > [1]: https://github.com/felipec/git-related >
