When visiting a file (blob) page provide a way to see the list of Open MRs targeting that file

Problem

We all know how painful conflicts are. Merge conflicts were a major theme in the August 2024 SUS Survey. Git and GitLab do a fairly good job at dealing with them when they happen, but how about avoiding them?

User scenarios

Common scenarios where a developer might try to mitigate merge conflicts using information about incoming MRs on a file might be:

• If several people are working on the same file in different branches
• When there is a refactor in flight that might renames/move the file
• When there is a migration of components
  • @psjakubowska "We had 3 sources of potential merge conflicts, and if we knew about those MRs ahead of time we could’ve mitigated the conflict ahead of time"

Relevant user feedback

• Users are interested in watching file changes: Issue (see upvotes and related closed duplicates)
• Users are interested in finding MRs open against specific files: Issue (open 3 years ago)

Jobs to be done

• JTBD: Check if anyone is working in this part of the code base right now.
  • Outcome: Decrease the chance of merge conflicts or lost work later in the software development lifecycle.
• JTBD: Monitor potential merge conflicts from other developers
  • Outcome: Minimize the risk of losing time or work due to merge conflicts.

Proposal

What if we could leverage the data we have at our disposal that is not in Git to promote more efficient collaboration by raising awareness of currently-in-flight work that could impact what you're doing?

Proposal: When seeing a specific file in the repository, add a way to see the list of Open MRs that touch that file.

Why is this useful information?

• Promoting efficient collaboration
  • Users can time contributions in a way that causes the least disruption to others work.
  • Knowing of incoming work is an opportunity for users to open conversations for collaboration.
• Raising awareness of in-flight work
  • Especially in the context of refactors that touch many files or simply rename some, knowing this information allows the contributor to plan accordingly.
  • This feature will raise awareness of in-flight work, which in turn will ensure that users can assess whether they should be making changes to that file, or if, for example, they should perhaps wait for a refactor to be completed before they make changes.
• Working towards preventing merge conflicts
  • Preventing conflicts is something that really fits within our strategy of enabling scale, particularly streamlining workflows with large repositories. The more users are working within a repository, the higher the likelihood that multiple tasks are impacting certain files.
• This feature leverages data that GitLab harnesses but Git isn't able to provide on its own.

Design

🎨 Figma | Design Discussion

Proposed desktop	Proposed mobile

Interactions

On hover, link the entire "card" row to the associated MR, similar to how we handle linking cards in Issue Boards. See #520125 (comment 2398942684).

card.mov

Implementation Breakdown

Context	Deliverable
#448868 (closed) (this)	By the end of Milestone 17.10 we will address (context): A badge to show the correct count of total number of open MRs associated with the file On hover, a popover with a list of MR titles
#520125 (closed)	Expand the dropdown to feature the extra MR information, per the mockup. Add to the UI a way to notify users of the query restriction (only MRs open in the last 30 days targeting this branch will be shown) Instrumentation Add feature tests

Implementation Details

• Spike
  • Development spike #469574 (closed)
  • POC GraphQL endpoint
• Performance considerations
  • It is recommended to scope the query for performance concerns. The POC query took 111ms where queries should max out at around 100ms. #448868 (comment 2147626873)
  • For performance reasons, we might want to make this call happen on-demand (at least to start with)
  • We can use progressive disclosure to initially show only a count of MRs. On click, show the list of MRs indicating “Showing only MRs for current branch (name_of_branch)”
• Query scope
  • It should list any MR which latest version includes at least one change to the current file. Minimum number of MRs to display is 1.
  • Display MRs targeting the current branch the user is viewing the file from. See #448868 (comment 2094131724)
  • For this first iteration, we only return MRs that have been created in the last 30 days.
• Front-end
  • Front-end breakdown
  • Potentially, we could re-use the popup that already exists when you hover over a link to a MR in markdown, if we don't want to reinvent the wheel + we could add missing info to those and impact a much wider surface area #448868 (comment 2112817529)
• Instrumentation
  • Please instrument the activity of this dropdown to get a general sense of engagement

Out-of-scope considerations

• Improving performance
  • In the first launch, we only return MRs that have been created in the last 30 days. In the future, it would be great to show all open MRs for the current file targeting this branch in my opinion. Even though MRs should be short-lived, there may be situations where an MR may be lingering. It may still be useful for users to be aware of these MRs for collaboration.
• Monitoring to see if functionality should be expanded
  • Gather feedback from users about usage and requests for expanded features like:
    • Seeing MRs across all branches for a specific file
    • Seeing MRs where the file on the current branch is the the source of the MR (first iteration of the feature will show MRs where the file on the current branch is the target of the MR)
    • See all open MRs on the current file, regardless of age (current iteration will only show MRs created in the last 30 days for performance reasons)
    • Seeing MRs for a specific queries to “See MRs for: [ Protected Branches ] [ All Branches]”
    • Show a count that shows: "Find/Count Open MRs that touch this file regardless of branch"
• Real-time conflict detection
  • This issue is a first iteration into what could become a more targeted and real-time conflict detection. Imagine if we could bring the awareness of the conflict not just at the file/MR level, but while you are actually making the code changes, allowing for instant conflict detection warning.
• Surfacing changes per code line
  • Perhaps after we have this feature, we might drill deeper and provide users context on changes made at the code line level.
• Helping users resolve/prevent merge conflicts
  • While this fix helps users by surfacing information, what are the most high-impact ways can we help users resolve/prevent merge conflicts? #491174