feat(dev-infra): merge script should link to original commit when cherry-picking with API strategy (#37889)

The merge script uses `git cherry-pick` for both the API merge strategy
and the autosquash strategy. It uses cherry-pick to push commits to
different target branches (e.g. into the `10.0.x` branch).

Those commits never point to the commits that landed in the primary
Github branch though. For the autosquash strategy the pull request number
is always included, so there is a way to go back to the source. On the other
hand though, for commits cherry-picked in the API merge strategy, the
pull request number might not always be included (due to Github's
implementation of the rebase merge method).

e.g.
27f52711c0

For those cases we'd want to link the cherry-picked commits to the
original commits so that the corresponding PR is easier to track
down. This is not needed for the autosquash strategy (as outlined
before), but it would have been good for consistency. Unfortunately
though this would rather complicate the strategy as the autosquash
strategy cherry-picks directly from the PR head, so the SHAs that
are used in the primary branch are not known.

PR Close #37889

dev-infra/pr/merge/strategies/api-merge.ts

@@ -135,7 +135,13 @@ export class GithubApiMergeStrategy extends MergeStrategy {
 
     // Cherry pick the merged commits into the remaining target branches.
     const failedBranches = await this.cherryPickIntoTargetBranches(
-        `${targetSha}~${targetCommitsCount}..${targetSha}`, cherryPickTargetBranches);
+        `${targetSha}~${targetCommitsCount}..${targetSha}`, cherryPickTargetBranches, {
+          // Commits that have been created by the Github API do not necessarily contain
+          // a reference to the source pull request (unless the squash strategy is used).
+          // To ensure that original commits can be found when a commit is viewed in a
+          // target branch, we add a link to the original commits when cherry-picking.
+          linkToOriginalCommits: true,
+        });
 
     // We already checked whether the PR can be cherry-picked into the target branches,
     // but in case the cherry-pick somehow fails, we still handle the conflicts here. The

dev-infra/pr/merge/strategies/strategy.ts

@@ -69,7 +69,8 @@ export abstract class MergeStrategy {
    * @returns A list of branches for which the revisions could not be cherry-picked into.
    */
   protected cherryPickIntoTargetBranches(revisionRange: string, targetBranches: string[], options: {
-    dryRun?: boolean
+    dryRun?: boolean,
+    linkToOriginalCommits?: boolean,
   } = {}) {
     const cherryPickArgs = [revisionRange];
     const failedBranches: string[] = [];
@@ -82,6 +83,14 @@ export abstract class MergeStrategy {
       cherryPickArgs.push('--no-commit');
     }
 
+    if (options.linkToOriginalCommits) {
+      // We add `-x` when cherry-picking as that will allow us to easily jump to original
+      // commits for cherry-picked commits. With that flag set, Git will automatically append
+      // the original SHA/revision to the commit message. e.g. `(cherry picked from commit <..>)`.
+      // https://git-scm.com/docs/git-cherry-pick#Documentation/git-cherry-pick.txt--x.
+      cherryPickArgs.push('-x');
+    }
+
     // Cherry-pick the refspec into all determined target branches.
     for (const branchName of targetBranches) {
       const localTargetBranch = this.getLocalTargetBranchName(branchName);