On Wed, 22 Oct 2014 11:56:30 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote:
> > > On 10/22/2014 11:33 AM, Michael S. Tsirkin wrote: > > On Wed, Oct 22, 2014 at 11:08:22AM +0200, Paolo Bonzini wrote: > >> The list emitted by --git-fallback often leads inexperienced contributors > >> to add pointless CCs. While not discouraging usage of --git-fallback, > >> we want to warn the contributors about using their common sense. > >> > >> So, default to *not* enabling --git-fallback, but print a message if > >> none of the files has a match against MAINTAINERS. Of course the > >> message is hidden by --no-git-fallback. > >> > >> Examples: > >> > >> 1) No maintainer for all specified files, print message: > >> > >> $ scripts/get_maintainer.pl -f util/cutils.c > >> No maintainers found. > >> You may want to try --git-fallback to find recent contributors. > >> Do not blindly cc: them on patches! Use common sense. > >> > > > > Does it make sense for util/cutils.c? > > I doubt it, so we are just giving useless advice? > > > > --git-blame might be a better fallback here? > > How about an entry in MAINTAINERS to trigger git-blame? > > We cannot know which is better. The right thing to do would be to use > git-blame *manually*, so as to find who touched the function you are > touching now. Maybe you could at least also add "--git-blame" to the message that is printed out here - so in case --git-fallback does not print anything at all due to the 1-year limitation, the user has at least another thing to try? Thomas
