On Mon, 2022-10-03 at 10:17 +0900, Akira Yokosawa wrote: > On Sun, 02 Oct 2022 16:55:05 -0700, Joe Perches wrote: > > On Mon, 2022-10-03 at 08:04 +0900, Akira Yokosawa wrote: > > > Hello Joe, > > > > > > Thank you for chiming in. > > > > > > On 2022/10/03 0:49, Joe Perches wrote: > > > > On Sun, 2022-10-02 at 09:58 +0200, Krzysztof Kozlowski wrote: > > > > > The easiest to achieve it is to run with --no-git-fallback and CC entire > > > > > output. However it does not mean submitter must run with > > > > > --no-git-fallback. It is only for this generic rule - CC entire output > > > > > of get_maintainers.pl. > > > > > > > > > > If you add such rule "CC entire output of get_maintainers.pl" and do not > > > > > mention no-git-fallback, some folks will think they need to CC all these > > > > > people who made one commit to your file... > > > > > > > > false. > > > > > > > > git-fallback is _not_ used when there is a listed maintainer for a > > > > specific file. > > > > > > > > If there is a use of git-fallback, it's because there is _no_ > > > > specified maintainer for a specific file. > > > > > > > > --git-fallback => use git when no exact MAINTAINERS pattern (default: 1) > > > > > > > > i.e.: It's not "your file" if you don't maintain it. > > > > > > Joe, I sometimes see unexpected output WRT --git-fallback. > > > > > > Example: > > > > > > $ ./get_maintainer.pl -f Documentation/doc-guide/sphinx.rst > > > Jonathan Corbet <corbet@xxxxxxx> (maintainer:DOCUMENTATION,commit_signer:1/1=100%) > > > <-- ??? > > > Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=100%) > > > <-- ??? > > > linux-doc@xxxxxxxxxxxxxxx (open list:DOCUMENTATION) > > > > > > linux-kernel@xxxxxxxxxxxxxxx (open list) > > > > > > As you see, --git-fallback is used in this case. Why? > > > It looks strange to me as Jon is listed as a "maintainer". > > > > > > Having "F: Documentation/" in MAINTAINERS does not suffice? > > > > No. It's not an exact pattern match as the files below the > > top level of Documentation are not specifically matched by > > "F: Documentation/". > For me, calling this is "not an exact pattern match" sounds > inconsistent with the explanation (quoted below) near the top of > MAINTAINERS: > > F: *Files* and directories wildcard patterns. > A trailing slash includes all files and subdirectory files. > What am I missing? > Does this explanation needs update? Maybe. Suggest some text. Read about the pattern-depth entries (basically, it's the count of forward slashes '/' in a maintained file pattern) Look for MAINTAINER entries where there are <foo>/*/ entries too. For instance: MAINTAINERS-INTEL ETHERNET DRIVERS MAINTAINERS-M: Jesse Brandeburg <jesse.brandeburg@xxxxxxxxx> MAINTAINERS-M: Tony Nguyen <anthony.l.nguyen@xxxxxxxxx> MAINTAINERS-L: intel-wired-lan@xxxxxxxxxxxxxxxx (moderated for non-subscribers) MAINTAINERS-S: Supported MAINTAINERS-W: http://www.intel.com/support/feedback.htm MAINTAINERS-W: http://e1000.sourceforge.net/ MAINTAINERS-Q: http://patchwork.ozlabs.org/project/intel-wired-lan/list/ MAINTAINERS-T: git git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git MAINTAINERS-T: git git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git MAINTAINERS-F: Documentation/networking/device_drivers/ethernet/intel/ MAINTAINERS-F: drivers/net/ethernet/intel/ MAINTAINERS:F: drivers/net/ethernet/intel/*/ <<< Here >>> MAINTAINERS-F: include/linux/avf/virtchnl.h MAINTAINERS-F: include/linux/net/intel/iidc.h So this entry is show that all of drivers/net/ethernet/intel/<foo>/ are directly maintained.
