Patches fail to apply with older versions of Git

[danepowell]

With Composer Patches 1.6.3, patches will silently fail to apply on machines with older versions of Git installed. I think it will fail for versions prior to Git 2.9.0, based on this commit: git/git@3f57944

Empirically, I've tested and verified that Git versions 2.11.0 and above work fine, while 2.7.4 and before fail. I haven't had time to build the versions in between from source in order to test.

I haven't yet determined whether this is a regression introduced by #165

I don't see why that would have caused a regression. But in testing, Composer Patches 1.6.2 works fine while Composer Patches 1.6.3 fails in at least one environment: acquia/lightning#524

I think the problem is that older versions of git apply silently fail to apply patches, so there's no way for Composer Patches to verify whether they've applied correctly or not. But again, I'm not sure how to reconcile that with the changes in acquia/lightning#524, which should have only been more aggressive in catching git apply failures.

[cweagans]

Le sigh.

git--

[danepowell]

I've confirmed this is a regression introduced by #165, specifically by the change in how we specify the git working directory.

I set up a vanilla docroot with drupal/core and downloaded a patch file to test with Git 2.1.4.

This is the "new style" command. It silently fails to apply the patch.
git -C . apply -p1 1356276-408--8.4.x.patch

This is the old style command. It applies cleanly (although also silently).
git --git-dir=. apply -p1 1356276-408--8.4.x.patch

I suspect that using the -C parameter triggers the Git bug/feature (depending on who you ask) of silently bailing when trying to use git apply in non-package repos: https://stackoverflow.com/a/27283285

[cweagans]

Do you have any suggestions for how we can get around this? One thought is that we could check for the presence of a .git dir, and only use git apply if it exists (otherwise, fall back to patch). What do you think about that?

[sylus]

I am so happy to have found this issue. Having a weird issue where all of my CI tests are green but my local docker devlopment is broken. Travis has git 2.14.1 and my local has git 2.8.4.

Confirmed this is what was causing my problem.

[angelHarizanov]

I can confirm that we have that same issue on a platform built using Acquia blt. My local git version is 2.13.0 while in the blt box it's 1.9.1. Hope this get's fixes soon as we cannot use @danepowell 's fork as blt requires the drush package which requires "cweagans/composer-patches". Hope this get's fixes soon.

[dakkusingh]

I had the same issue, my ubuntu 16.04 install shipped with Git 2.7.4 as this is the highest version out of the box.

After updating the git version with:

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git
	
git --version
git version 2.15.1

After a quick git upgrade, I can confirm the patching behaviour to be working as expected.

Cheers again for finding the issue.

[danepowell]

A fix is pending in #175, but for anyone that needs an immediate workaround, you can pin composer-patches to 1.6.2 or use my fork. Add the following to your composer.json:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/danepowell/composer-patches"
        }
    ],
    "require": {
        "cweagans/composer-patches": "dev-issue-174 as 1.6.2",
    }
}

Depending on what other dependencies you have installed, you might need to change the alias to 1.6.3.

[benjaminrau]

The fix provided by @danepowell works for me! Thanks a lot.

[williambe]

My local system is a macOS 10.11.6/composer 1.5.5/git 2.15.1/GNU Patch 2.7.5

With git 2.15.1 patches are always silently failing (tested with composer-patches version 1.6.3/1.6.2/dev-issue-174 as 1.6.2)

If I switch back to git 2.13.4 (thanks to theneonlobster acquia/blt#2251 (comment)) it still fails with 1.6.3 and @danepowell fix (thanks anyway) but succeeds with version 1.6.2

My two cents workaround is: switch back to git 2.13.4 + cweagans/composer-patches:1.6.2

[danepowell]

@williambe did you make sure to complete nuke composer caches during your testing? That includes removing composer.lock, the vendor directory, docroot/core/modules/etc, and running composer clear-cache. If those patches previously failed to apply, then those bad results might be cached even after you update your composer patches version.

[williambe]

During each test I've always nuked docroot, vendor, composer.lock. I've runned composer clear-cache only sporadically. However, during test regarding your fix, I've always checked resulting composer.lock to be sure that 'cweagans/composer-patches' was the one from your custom repository. I volunteer for other tests, if you want.

[danepowell]

@williambe if you can debug on your machine or confirm with further testing, or provide the log output of composer install -vvv / composer update -vvv so we can help debug, that would be appreciated.

Your observations are not consistent with mine. I have tested all versions of composer patches (1.6.2, 1.6.3, and my PR) extensively on Mac OS 10.13.1 running the same Git/Patch/Composer versions as you, and I've never had a problem. As long as Git and Patch are up to date, any version fo composer-patches should work.

Note that if you are running composer commands with the verbose flags, you might observe errors/warnings but the patches are still correctly applied.

[williambe]

@danepowell I have done more tests, saved all in a repository, https://github.com/williambe/composer-patches-test
three branches, in each branch the output of composer install -vvv saved in a txt:

• git251-composer-patches163 (patching fails)
• git251-composer-patches#174 (patching fails)
• git234-composer-patches162 (Stranger Things, patching happens with Drupal 8.4.2 but it fails with Drupal 8.4.3patching happens)

In the hope that it will be useful and does not just make you waste time. Thanks.

[hussainweb]

This fix works for me as it removes the root problem with 'git apply'. I want to point out the edge case with git 2.1.4 where the fix in #165 didn't work because git-apply would not output the 'Skipped patch' messages, even if it skipped those patches. That functionality only appeared in git 2.15.1.

On a sidenote, the command git apply --directory <installed_path> -p1 <patch_name> worked fine for me, even if the root path or the package being patched themselves were not git repositories (I tested both with and without .git directory in the root). In any case, this change fixes the issue for me. I am just writing this for documentation.

[cweagans]

I think we're good here now unless anyone has objections.