Cherry-picking a MR doesn't keep the permissions of a moved and re-permissioned file in destination branch
Summary
Cherry-picking a MR doesn't keep the permissions of a moved and re-permissioned file
Steps to reproduce
- Create a clean repository
- Add a file to master, "file", chmod it 755, commit
- Create another branch, let's call it
version
and make any merge request there, let's call it MR1 tumikk/gitlab-cherry-pick-bug-example!1 (merged) - In branch master, do 'git mv file newFile' and chmod the newFile to 644 (tumikk/gitlab-cherry-pick-bug-example@2662072d)
- Try to cherry-pick MR1 to master
- -> MR2 is created, which includes contents of MR1 but also a chmod of newFile to 755 tumikk/gitlab-cherry-pick-bug-example!2
Example Project
Example project: https://gitlab.com/tumikk/gitlab-cherry-pick-bug-example
MR1: tumikk/gitlab-cherry-pick-bug-example!1 (merged)
MR2 (cherry-picked MR1 into master): tumikk/gitlab-cherry-pick-bug-example!2
What is the current bug behavior?
MR2 reverts the permission change that is in master, in a file totally irrelevant to the merge request that is being cherry-picked.
What is the expected correct behavior?
MR2 is a cherry-pick of MR1, so it should only include changes from MR1
Relevant logs and/or screenshots
Please see MR1 and MR2 of example project
Here is the graph, here the topmost commit is the cherry-pick of the last merge in "version" branch. That cherry-pick reverts the chmod done in master just before.
Output of checks
This bug happens on GitLab.com and installed gitlab-ee
Other info
Based on my tests, this bug only happens if the file has been both moved (git mv) and re-permissioned. Either of those alone works fine.
Happy to give more information if needed - we are hitting this every time we cherry-pick changes to a branch which has a moved and re-permissioned file in the history.