<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes Support the ability to render a rich diff of the contents found inside a binary patch file contained in a snippet. ### Problem to solve Snippets are a convenient way to share patches with other users. If a patch contains plain text, the default syntax highlight is enough to easily interpret the patch. For example: >  However, when examining binary patches, the results are not always ideal: >  It would be nice, in the event that GitLab supports a compatible rich diff capability, that it could render a portion of the patch in some manner as visible in a commit diff: >  ### Intended users Designers and developers. ### User experience goal A user will be able to share a snippet with another user that contained a binary patch, and users viewing the snippet can view the proposed changes without needing to download the snippet and handle the patch comparison externally. ### Proposal A crude overview would be as follows: - Detect that the snippet file is a `.patch` (diff) file. - Examine the patch and look for specific file parts within the diff which can be rendered in a normal text format, a rich format or a default hex-view binary format (like the existing rendering). - When rendering parts of the patch, for the rich content, display a respective view in a similar fashion which exists for commit diffs. Adding and removing (`/dev/null`), for example, an image would still render the content (with an indication that it is being added/removed). ### Further details - Provides an easy way to share technical data between users with increased usability which may not be easily shared/examined via other channels. ### Permissions and Security n/a ### Documentation n/a ### Availability & Testing n/a ### What does success look like, and how can we measure that? n/a ### What is the type of buyer? n/a ### Is this a cross-stage feature? n/a ### Links / references n/a