Select file encoding for import/export of source files

[gitqube]

I use the sync Project function export and import for managing my VBA sources in GitLab. The export of the VBA files is in ANSI (cp-1252), and the file handling on GitLab side is UTF-8. This is fine as long as there are no special characters, e.g. german 'ä' or 'ü' within the files. But if so, I get in trouble when trying to change anything inside the Webinterface of GitLab. The files then are handled as UTF-8 and characters are corrupted, when pulling files and re-importing to VBA project.
My suggestion is, to provide a new conversion possibility withing the RD Sync function, to be able to select the file encoding on the file side.
This would mean to convert all text-files (.bas, .doccls, .cls) from cp-1252 to UTF-8 (or maybe some other selectable encoding) after exporting, and the other way round before importing.

[Vogel612]

This is less reasonable than one would think :)

The VBE natively stores the code in the relevant windows code page, which may or may not be cp-1252. The proper way to handle this is to mark the files as the appropriate encoding with git attributes so that gitlab does not mangle them.
The way to do that would be to add the following lines to the .gitattributes file:

*.bas         text working-tree-encoding=CP-1252
*.doccls      text working-tree-encoding=CP-1252
*.cls         text working-tree-encoding=CP-1252

the working-tree-encoding value might need to be the equivalent ISO-8859-1 to make sure it works. Relevant git documentation can be found here

[gitqube]

Thank you for your answer :-)
Indeed this also was my first approach. I tried it with CP1252 and also ISO-8859-1, but it does not change anything. When checking git check-attr -a myfile.cls everything appears to be correct, and in theory, files should be checked in as UTF-8. But actually the text files are checked in as CP1252, like if they were binary files. And viewing in GitLab appears mangled, and editing inside GitLab corrupts the files.
So my next approach was to use git hooks pre-commit and post-checkout to do a conversion with iconv. But this is more a workaround than a solution and brings some new tumbling-stones in daily use.
This led me to propose the conversion as a new Rubberduck feature, I think it would make life easier.

[gitqube]

ok, I think I have found the reason. As I wrote, 'in theory' it should work, but didn't. I tried everything again in git bash, and tadaa! Conversion works. During my first tries I used a tool named "GitAhead" for commit, push and pull, and it seems to ignore my .gitattributes... sigh