How target specific version of fork based merge request (MR) patch

There's more than one way to apply a one-off patch to a Composer-based PHP project. The classic way is to use cweagans/composer-patches, which is the way you have learned.

This article explains in detail how to use Composer Patches to patch Drupal core.

You may be able to use this method to apply this patch, which is the approach recommended by @catch in this comment, by including this in your composer.json:

    "extra": {
      "enable-patching": true,
        "patches": {
          "drupal/core": {
            "Allow Views exposed sort identifiers to be configured": "https://git.drupalcode.org/project/drupal/-/merge_requests/54.diff"
          }

As @catch mentions:

@Giuseppe87 you can use https://git.drupalcode.org/project/drupal/-/merge_requests/54.diff - although to get a stable patch to apply, it's best to download this to a /patches directory in your codebase, and then add the local patch path to composer.

To follow these instructions, open a Terminal and cd to the project root directory of your Drupal 9.2 project, then execute the following commands:

$ mkdir patches
$ cd patches
$ wget https://git.drupalcode.org/project/drupal/-/merge_requests/54.diff
$ mv 54.diff configure-views-exposed-sort-identifiers.patch

To use the local patch file in your project rather than the remotely-hosted patch on Drupal.org, your composer.json would look like this:

    "extra": {
      "enable-patching": true,
        "patches": {
          "drupal/core": {
            "Allow Views exposed sort identifiers to be configured": "patches/configure-views-exposed-sort-identifiers.patch"
          }

Using a local file is considered the best practice here, since it has some advantages over using a remote file. It's both more secure and more efficient.

There's another, relatively new, method to apply patches by opening up an Issue Fork and my initial answer recommended that method, but it's not necessary here.

EDIT: After reading your comments below, it looks like your problem is that !54 was never applied to the 9.2 branch before rebasing.

Going back to the MR on GitHub, you can roll back the last two commits by choosing "Version 9" of the MR:

But even then, the target is set to 9.3 and it's not clear how to change it using the web-based UI.

You'll need to follow the Git Instructions to clone Drupal core to a local development environment:

$ git clone https://git.drupalcode.org/project/drupal.git
$ cd drupal

Then, go back to your Issue Queue and look at the instructions to check out the branch for an Issue Fork:

$ git remote add drupal-2897638 [email protected]:issue/drupal-2897638.git
$ git fetch drupal-2897638

Also check out the 9.2.x branch:

$ git checkout -b '9.2.x' --track drupal-2897638/'9.2.x'

Now, you want to generate a diff between the state of the project at commit eaa43b0c and the 9.2.x branch:

$ git checkout eaa43b0c
$ git diff drupal-2897638/9.2.x > configure-views-exposed-sort-identifiers.patch

This will generate a patch between the commit you have identified and the 9.2.x branch.

However, this may still not be what you want. The patch generated by this method is more than 230,000 lines of code:

$ wc -l configure-views-exposed-sort-identifiers.patch                    
230134 configure-views-exposed-sort-identifiers.patch

It's possible that the git commit you have identified was always based on the 9.3.x branch. It seems that there is more work to be done in order to recreate the essential work for this patch and apply it cleanly to the 9.x branch.

It's difficult to say for sure, because eaa43b0c is already 93,000 lines of code ahead of the 9.3.x branch:

$  git diff 9.3.x |wc -l
93794

It's easy to take for granted how much work people put in to this open source software that we all rely on. If you require the functionality supplied by this patch, the easiest way to get it will be to upgrade your Drupal project to the 9.3.x branch a bit sooner than you'd have preferred to do so. Then the patch will apply cleanly, and you won't need to understand those 93,000 lines of code.

One last note -- the diff generated by Merge Request 54 is less than 1000 lines of code:

$ wc -l 54.diff                                                          
936 54.diff

You might be able to check out the 9.x branch and apply each of those 936 changes by hand in order to generate the patchfile in your local. It would still be a lot of work, but maybe less work than some of the other options.

This is not a common situation; most Composer Patches are smaller than this monster by orders of magnitude.

Good luck!