build: exclude redundant cherry-picked commits when generating changelog

[clydin]

If generating a changelog between tags that are on different branches (e.g., 9.0.3 on 9.0.x and 9.1.0-next.0 on master), commits that were cherry-picked and present in the previous version would also show in the newer version's changelog. This update analyzes the commits and excludes any that fit this scenario. Any commits that had conflicts will not be able to be matched authoritatively. Manual review of the generated changelog may still be needed for attempted cherry-pick commits that had conflicts.

[dgp1130]

Typically when I cherry-pick commits I include the -x flag, which leaves a reference in the commit to the original hash. Would it be possible to use this to identify cherry picks which were modified due to merge conflicts?

Assuming caretakers always add -x (which we could probably enforce somehow on release branches) and always cherry pick from master (which itself should include the "original" commit, not another cherry-pick), then reading that value would always get the authoritative commit hash. That hash should be stable, even if a merge conflict was fixed.

Could we compare these "authoritative" hashes to identify the new commits and generate a changelog from that set?

[clydin]

The -x option only applies to cherry-picks without conflicts. There's also no guarantee that the option will always be used so the patch-id method that compares the diffs of the commit would still need to be used. This is also more authoritative since the commit message could erroneously contain the inserted text and point to an arbitrary commit.
The -x option should definitely be used when possible though since it provides an easy way for a user to relate the commits when reading through the history.

[dgp1130]

The -x option only applies to cherry-picks without conflicts.

Not true, I just had this happen while merging #17040. I did a git cherry-pick -x and hit a merge conflict. After fixing it, I ran git cherry-pick --confinue which generated a commit message including the cherry pick line: 35ad92c.

I would imagine there's a way to put a restriction on release branches that they must contain the -x info. If we did require this, could it be a more stable way of identifying commits? That way we don't need to manually check for merge conflicted commits (which I can't imagine anyone would take the time to do).

[clydin]

The documentation for the option says it doesn't (https://git-scm.com/docs/git-cherry-pick) so I'm not sure we should rely on the behavior. But we could augment the check to also try to find the text and analyze the referenced commit if no initial match is found.

This doesn't cover the case where separate PRs are created due to the conflicts though. From my manual review of 9.1.0-next.0, this was the more common case.

[dgp1130]

Interesting that -x does work with merge conflicts even though it is explicitly documented not to. Agreed that we probably shouldn't rely on this seemingly incorrect behavior. Also agreed that this doesn't address separate PRs to the release branch, so we'd still need to do the patch id trick there. Just wanted to see if utilizing -x could be better, but seems like it really wouldn't.

[clydin]

Yes. I agree, I was hoping it would be more useful especially since I noticed you started using it when cherry-picking.
I'll do some further experiments with trying to further reduce the extra commits. While this PR isn't a perfect solution, it is a pretty good one (90+% of the commits were removed).

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}