Could not reset changes, using composer with Shopware

The could not reset changes error might indicate a problem with file permissions, and you may have to fix the permissions and re-install the package via composer to fix it.

206 views
d

By. Jacob

Edited: 2023-12-30 17:00

I noticed the Could not reset changes error in GitDownloader.php, seemingly triggered from line 560 (just adding to the confusion), when trying to run sudo -u www-data composer update on a composer managed Shopware 6 plugin that we install from our GitHub. The exact error may look something like this:

tpy/handler has modified files:
    M src/Resources/public/administration/css/tpy-handler.css
    M src/Resources/public/administration/js/tpy-handler.js
    M src/Resources/views/storefront/element/cms-element-tpy-handler.html.twig
    Discard changes [y,n,v,d,s,?]? y

In GitDownloader.php line 560:

  Could not reset changes

  :

Meaningless? Not quite. But super confusing, because most of us will probably need more explanation and context then that. If you read carefully, it tells us that some files has been modified, and in that context the "Could not reset changes" error may hint at a problem with either permissions or git. I am leaning mostly towards this being a permission issue, but I can not tell for certain because files got deleted automatically as I was trying to solve the problem. As for the colon at the end, yes that was part of the error message, and it seem to serve no other purpose than to make you think something is seriously broken. I do not like lonesome characters appearing in output without explanation, it is just too ambiguous! Ok, let us ignore the colon!

1. I solved the problem by navigating to the plugin fulder and typing:

sudo -u www-data git stash

This stashes the local changes, and should allow running composer update vendorname/pluginName.

2. However, in my case even this was not enough, as the file permissions of some of the plugin files had also changed. Composer is not super helpful, because rather than simply telling you that you got a permissions issue, it just tells you that it was unable to delete a file. E. g:

In Filesystem.php line 301:
  Could not delete /var/www/shopware/vendor/tpy/handler/src/Resources/views/storefront/element/tpy-handler.twig

If you check the permissions on the file, then it might tell you that the file has the wrong ownership. E.g:

ls -alh /var/www/shopware/vendor/tpy/handler/src/Resources/views/storefront/element/tpy-handler.twig
-rw-rw-r-- 1 jacob jacob 282 Dec 24 14:23 tpy-handler.twig

This can happen when a user creates the file from their own user account, and trust me, I have done this numerous of times. Mistakes happen when you dance around your keyboard and you are in a hurry. The solution is to change the ownership manually. Remember, you might be running composer as www-data, so naturally it will be prevented from updating when the permissions are not right.

Of course, there are ways to avoid files being created with wrong permissions. E.g. setgid and setuid, but this may not be recommended. Although I doubt it to present "huge" security issues, you should probably not do that. I disslike the idea today, but basically it would mean that newly created files in a folder automatically get the same predictable permissions. It is a neat little trick I used a few times back when I was SFTPing files to my servers.

3. The best solution is probably to just be mindful of the situation. When you know why it happens, and how to fix it, perhaps it is not really much of a problem. E.g:

sudo chown -R www-data:www-data /var/www/shopware/vendor/myplugin/
sudo chmod -R 775 www-data:www-data /var/www/shopware/vendor/myplugin/

4. Even after fixing the permission issue, I had to re-install the plugin, because it complained about missing .git directory. E.g:

sudo -u www-data composer require <repository name>:dev-<branch-name>

The error about the missing .git directory can look like this:

Update failed (The .git directory is missing from /var/www/shopware/vendor/myplugin/, see https://getcomposer.org/commit-deps for more information)

Will I loose data?

Who knows? Right? This is Shopware after all, so I would recommend taking frequent backups.

In my case, luckily nothing happened to the plugin or its associated data in the database doing this process. But, we really ought to be careful!

When I was uninstalling a blog plugin for Shopware recently, I actually lost the associated data, and I had to import a backup of the database. Be very careful!

Tell us what you think:

  1. How to debug issues caused by corrupted custom fields in Shopware 6.
  2. Sometimes we may to manually clear cached Shopware files to fix namespace issues.
  3. How to obtain the currently selected API language from Shopware vue components.
  4. How to access file system paths from storefront twig files in Shopware.
  5. How to get or change the currently selected sales channel in an Shopware sw-sales-channel-switch component.

More in: Shopware