RFR: 2588: Auto Labeling should ignore merge commits

[Erik Joelsson]

On Wed, 17 Sep 2025 15:50:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

There are problems with this approach. 

1. Say the user pushes two commits, in the first it touches file A, then realizes it was a mistake and reverts that change in the second commit. If those two commits are pushed together, then before this patch, file A wouldn't appear in the diff, but with this patch it does.
2. I don't think we can make the assumption that the first parent will always be the correct one to follow in a merge commit.

I think I have figured out a better algorithm, but I'm not sure yet:
First find all commits that are ancestors of the PR head, but are not present in the target branch, this is the complete set of PR commits. Then iterate backwards from `to` until you find a merge commit or the `from` commit. Take the diff from all commits passed this way combined and extract changed files. Then if this was a merge commit, pick all parents that are in the complete set we collected earlier and continue this way until reaching the `from` commit.

This will group any consecutive commits between merges to at least alleviate most of the potential issues from 1, but not all, so I'm still unsure if this is good enough. It will guarantee that we only consider commits in the PR and not anything already present in the target branch. 

Maybe for the initial labeling, we can skip this algorithm completely and just diff PR head with mergebase. At that time, that diff is guaranteed to be correct at least.

-------------

PR Review: https://git.openjdk.org/skara/pull/1740#pullrequestreview-3236106538