On Fri, Apr 19, 2013 at 2:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> On Fri, Apr 19, 2013 at 12:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >>>> The code finds the changes of a commit, runs 'git blame' for each chunk >>>> to see which other commits are relevant, and then reports the author and >>>> signers. >>> >>> In general, I am not all that interested in adding anything new to >>> contrib/ as git.git has matured enough, but even if this will stay >>> outside my tree, there are a few interesting things to note to help >>> its eventual users. >> >> Why not add it to mainline git then? This tool, or a similar one, >> would certainly be useful in the git arsenal. > > As to this particular "feature" (the goal it tries to achieve, not > necessarily the implementation), that actually was the first thing > that came to my mind. It helps the "develop, review locally, > format-patch, decide whom to ask reviews and then send it out" > workflow in general to have a tool that tells you who are the people > involved in the code you are touching. > > If this were _only_ to be used within send-email (i.e. replacing the > "then send it out" above with "then use send-email" to limit the > usecase), "git cc-cmd" would be a reasonable name. But if that is > the intended use case, it would even be more reasonable to make this > logic part of send-email and trigger it with --auto-cc-reviewers > option or something. Yeap, but I wouldn't want to be the one that implements that in perl. > But I think it can be useful outside the context of send-email as > well, and having one independent tool that does one single job well > is a better design. Perhaps it is better to name it less specific > to send-email's cc-cmd option. "git people"? "git whom"? "git > reviewers"? I dunno, but along those lines. 'git relevant'? 'git related'? It's not only people, also commits. > It is OK for a design demonstration prototype to be written in any > language others (who can comment on the design) can read, but the > version to be a first-class citizen needs to be written in one of > the languages such as C, POSIX shell, or Perl to avoid adding extra > dependencies to the users. That is going to be though. Cheers. -- 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