@servicedesk Please propose a solution. What we're trying to use: existing code, UX elements, etc.

We do not want to compromise on speed and performance.

Don't assume. Ask high-level clarifying questions if needed.

• Numbered questions (1, 2, 3, etc)
• Lettered answer options (A, B, C, etc)
• Pros and Cons? Your recommendation?

@zaakiy Proposed approach below, plus clarifying questions.

Proposed solution

Reuse the same commit-hash UX already used on PR update activities (PullRequestUpdatePanel) and commit info (CommitInfoPanel):

• abbreviated hash via GitUtils.abbreviateSHA
• link to CommitDetailPage via ViewStateAwarePageLink
• one-click copy via CopyToClipboardLink

Render that control next to the merge activity line in PullRequestChangePanel when the change is a PullRequestMergeData.

Data source (no git lookup)

For merges performed through OneDev, PullRequest.mergePreview.mergeCommitHash is already persisted on the PR after merge (DefaultPullRequestService.merge / closeAsMerged(..., false)). Reading that field at render time:

• needs no schema/migration
• needs no git resolution
• is already loaded with the PR (embedded MergePreview) — no extra query / no performance cost on the Activities tab

PullRequestMergeData today only stores an optional reason string ("merged" / "merged pull request"), not a hash. Externally detected merges clear mergePreview, so those would not show a hash under a preview-only approach.

Recommendation

UI-only change: show hash+copy+link from existing mergePreview.mergeCommitHash when present. Matches the issue scope (“merged through OneDev”), reuses existing UX components, and preserves speed/performance.

Optional hardening later (not required for the stated need): also store the hash on PullRequestMergeData at merge time so it stays on the activity even if preview data were cleared.

Clarifying questions

1. Which merges should show the hash?

   • A. Only merges through OneDev (where mergePreview.mergeCommitHash exists) — recommended; matches issue description
   • B. Also attempt externally detected merges when a commit can be inferred
   • C. Store hash on merge activity data going forward, and fall back to mergePreview for older OneDev merges

   Pros/cons: A is cheapest and sufficient; B adds complexity/edge cases; C is more durable but needs a small model change for new merges.

2. Where should the hash appear on the activity line?

   • A. Inline after the verb: User merged a1b2c3d [copy] N ago — recommended; matches the screenshot callout
   • B. Trailing actions style like update commit rows (hash + copy on the right)
   • C. Other placement you prefer

3. Historical already-merged PRs?

   • A. Show whenever mergePreview.mergeCommitHash is still present (covers existing OneDev-merged PRs with no backfill) — recommended
   • B. Only show for merges after this fix ships
   • C. A + also persist hash on new merge activities for future durability

4. Notifications / emails?

   • A. Activities UI only — recommended for this minor improvement
   • B. Also include the hash in merge notification text

Please reply with your choices (e.g. 1A, 2A, 3A, 4A) or adjustments.

Implemented the requested Activities UI update. Merge activities now show the abbreviated merge commit hash inline with a link to the commit and a one-click copy control whenever the persisted merge preview hash is available. This reuses the existing commit UX and performs no additional repository lookup.

Validated with mvn -Pce -pl server-core -am -DskipTests compile (BUILD SUCCESS).

Submitted as pr OD-101.