HOWTO: advanced filters check for file rename only

[iamtodor-fb]

Hello,

I find the following options https://github.com/dorny/paths-filter/blob/master/README.md?plain=1#L446
I was able to configure not to run linter on deleted python files by having the filter

with:
          list-files: 'shell'
          filters: |
            py_scripts_filter:
              - added|modified: '**/*.py'

But it does not work on renamed files: R: renaming of a file: https://git-scm.com/docs/git-diff/2.12.5.

Let's say you have a foo.py, you renamed it to bar.py, and you did not modify the file's content but the linter still runs against it.

Is it possible to configure the linter not to run on this kind of change?

[petermetz]

Not sure if I have the exact same or just a similar issue, but here we go:
I noticed that renames are ignored altogether: https://github.com/dorny/paths-filter/blob/master/src/main.ts#L185-L187
and would like to have an option/flag/etc. to include them because in some of the languages we use renaming the file can break the build quite easily if references to that file were not updated correctly (think of import statements in Typescript).
Based on that, we would prefer to be extra cautions and detect renames as meaningful changes that trigger test execution which would then tell us that there were bugs in the diff that did the renaming.

[dorny]

@petermetz Looking at the code, it seems I've intentionally implemented rename to be equal to deleting and adding the new file. I wrote this part a long time ago so I don't remember all details now. I'm open to using a config parameter to change this behavior while keeping the default as it is now to avoid breaking changes.

If you prepare PR, I will review it as soon as possible. Otherwise, I can't promise when the feature will be available.

[petermetz]

@petermetz Looking at the code, it seems I've intentionally implemented rename to be equal to deleting and adding the new file. I wrote this part a long time ago so I don't remember all details now. I'm open to using a config parameter to change this behavior while keeping the default as it is now to avoid breaking changes.

If you prepare PR, I will review it as soon as possible. Otherwise, I can't promise when the feature will be available.

@dorny A very reasonable proposition, thank you! I'm also quite short on time and this is not a high priority item for us either, so it might take a while, but I'll certainly look into sending a PR. Thank you very much for taking the time to evaluate the issue and also thank you for the great tool/project in general!