Downloading a patch file from a merge request
You can download a patch file directly from an issue by clicking the plain diff link at the top of an issue
Or, while on the MR page from the Plain diff button in the download menu of an MR (See screenshot).
You can also get a patch file for any merge request by appending .patch to the end of the url. For example, if this is your merge request:
https://git.drupalcode.org/project/drupalorg/-/merge_requests/17add '.patch'
https://git.drupalcode.org/project/drupalorg/-/merge_requests/17.patch to get a patch url to download the patch. Do not use the patch URL directly, read the warning below for more information.
The patch resulting from adding .patch has separate changes for each commit. When the MR is long and has several changes to the same files, including file renames, the resulting patch file may not be useable. In this situation, you can replace .patch with .diff to get a simpler patch file with each file only appearing once but containing consolidated changes for the whole merge request.
Also note that if more commits are added to the merge request, the patch that you can download from that URL will change. You must, download the patch file and save it locally.
Patch files for use with Composer
While project maintainers may not require patches and can handle merging and testing themselves with Git remotes, non-maintainers trying to test an issue will be greatly helpedby a patch file. Patch files also allow for faster delivery of changes across multiple test environments.
Composer can only get patch files applied to the code and can't deal with commits from forks without extra burden. Luckily Gitlab provides patches both for single commits and for Merge Requests.
Patch files are also useful if you use bash patch -p1 < file or git apply patch
Patch files can be obtained for both single commits and Merge Requests. There are two methods for getting the patch file:
- By appending .patch at the end of the url displayed in gitlab when viewing a commit or a Merge Request.
- By using the Email Patches option in the Gitlab UI.
An example using method 1:
If you're looking at a merge request, for examplehttps://git.drupalcode.org/project/drupal/-/merge_requests/20 you can append .patch to the url to obtain a patch file like so:https://git.drupalcode.org/project/drupal/-/merge_requests/20.patch
More details on method 2 through the Gitlab UI:
To get a patch file for a single commit navigate to the commit page, click on Options and select Email Patches:
To get the patch for a Merge Request that consists of several commits navigate to the overview of the MR, click on the "arrow down" icon and then click Email Patches:
In both cases, download the patch file to your site’s codebase andadd the pathto the patch file to your composer.json file.
See Composer-Patches: The Dependency You Never Knew You Needed for a tutorial on how to add a patch to your composer.json file
The contents of merge request patch file will change as commits are pushed!
This means that you will get the latest version of the code from an issue.So, it brings a security risk because any new commit to the issue’s branch will be automatically deployed to your site when composer runs.
It's strongly recommended to lock the patch file versions on production sites. To do so you must download the patch file and use it in composer from a local directory. If you use theURL to the Gitlab MR directly, your codebase will change without warning, as people work on the merge request.
You can still use git diff to generate patches, and attach with an issue comment in the usual way. Rather than generating an interdiff.txt file, you can link to GitLab’s Merge Request (MR) or Commit page to get the diff between two stages/commits.
Creating a patch file of a Merge Request for an older stable release
Most Merge Requests will target the latest version of Drupal that is under active development while a different version is the recommended stable version for a production site (eg, such as 11.x under development while 10.2.x is the latest stable branch). In many cases the patch will still apply, but sometimes you may come across a conflict. In this case if you want to create a patch of the Merge Request that applies to 10.2, you need to git cherry-pick all the commit IDs in the branch into the target version of Drupal and resolve the conflicts.
For example:
git clone DRUPAL-GIT-REPO folder-namecd folder-namegit remote add drupal-ISSUE-NUMBER https://git.drupalcode.org/issue/drupal-ISSUE-NUMBER.gitgit fetch drupal-ISSUE-NUMBERgit checkout -b PATCH-BRANCH-NAME refs/tags/STABLE_RELEASEgit cherry-pickFIRST-COMMIT-ID-IN-BRANCH..LAST-COMMIT-ID-IN-BRANCHgit diff refs/tags/STABLE_RELEASE > PATCH-FILENAME-HERE.patchNote here that everything in all capital letters should be replaced.
