On Fri, 7 Jan 2022 at 10:54, Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote: > My big worry would be backporting for the next 2 years. > Do we need to adjust commit messages when backporting to replace *.cc with > *.c in there? Does git cherry-pick handle the changed files or do we > need to resolve conflicts manually?
git cherry-pick (and the gcc-backport alias) should handle it automatically, unless the diffs between trunk and the branch are a large percentage of the whole file. IOf a file has been renamed then Git finds the file to apply the patch to by comparing file contents fuzzily. For a large repo like GCC you might want to set the merge.renameLimit config variable so that it doesn't give up trying to find the file too early. I did 'git config merge.renameLimit 9001' in my repos. You can also set it to 0 which uses a hardcoded maximum decided by Git, which gets updated now and then to ensure it works for the kernel. That maps to a value much larger than 9000, but I've found that my GCC cherry picks work with 9001. References to .cc files in the commit message won't get changed to .c automatically, but maybe the gcc-backport alias could be taught to do that.
