[JENKINS-23606] Git Polling Jobs with Included Regions being triggered unnecessarily with merge commits

We have a single Git repository with several projects in a directory structure. I have created build jobs with polling enabled for each project and have included the appropriate directory structure in the "Included Regions" option in the git plugin setup. I have also turned on "Force Polling using Workspace" as indicated in https://issues.jenkins-ci.org/browse/JENKINS-20569.

We are using a git-flow type development process, and the jobs are all configured to watch the '*/dev' branch. All commits made to this branch are merges. It appears that whenever a merge commit is made, it will trigger all of the jobs, regardless of if the merge only contained changes to one of the projects' directories.

I looked into the polling log and it looks like the way that the plugin is getting the commit log and checking the paths may be causing the issue. Here is the command that the job runs in the polling log:

> /usr/bin/git log --full-history --no-abbrev --format=raw -M -m --raw ff0ec94a066cee23c13faa16b38b247911cd5ee7..f47993565f701a4f28174c4ea81f35d0e1103590

If I run this command manually, I can see that the returned paths for each commit also includes paths from other commits. I'm not sure why this is, but from the 'git' documentation, it looks like the '-m' parameter will do a full diff on both parents of a merge commit. If I leave off the '-m' parameter, or if I include '--first-parent', the list of paths in the commits only shows the actual affected files made by the commit which triggered the job. Perhaps this option needs to be included in the job config?

We have a single Git repository with several projects in a directory structure.  I have created build jobs with polling enabled for each project and have included the appropriate directory structure in the "Included Regions" option in the git plugin setup.  I have also turned on "Force Polling using Workspace" as indicated in https://issues.jenkins-ci.org/browse/JENKINS-20569.

We are using a git-flow type development process, and the jobs are all configured to watch the '*/dev' branch.  All commits made to this branch are merges.  It appears that whenever a merge commit is made, it will trigger all of the jobs, regardless of if the merge only contained changes to one of the projects' directories.

I looked into the polling log and it looks like the way that the plugin is getting the commit log and checking the paths may be causing the issue.  Here is the command that the job runs in the polling log:

 > /usr/bin/git log --full-history --no-abbrev --format=raw -M -m --raw ff0ec94a066cee23c13faa16b38b247911cd5ee7..f47993565f701a4f28174c4ea81f35d0e1103590

If I run this command manually, I can see that the returned paths for each commit also includes paths from other commits.  I'm not sure why this is, but from the 'git' documentation, it looks like the '-m' parameter will do a full diff on both parents of a merge commit.  If I leave off the '-m' parameter, or if I include '--first-parent', the list of paths in the commits only shows the actual affected files made by the commit which triggered the job.  Perhaps this option needs to be included in the job config?

• environment: Git Plugin 2.2.2, client plugin 1.9.1, Jenkins 1.568

Start with the git-plugin polling log and reproduce the reported command using a merge commit, comparing git log with and without -m and --first-parent. Trace how polling evaluates the Included Regions path restriction. Done means merge commits trigger only jobs whose included directories actually changed, with regression coverage for this behavior.