On z/OS, git apply --3way correctly converts file content according to the configured zos-working-tree-encoding / working-tree-encoding attribute, but fails to apply the expected file tag to the resulting merged file.
The merged file content is correct, however the file tag falls back to the default system tag (typically ISO8859-1/UTF-8) instead of the encoding specified in .gitattributes.
This issue appears specific to the --3way merge path.
Expected Behavior
After git apply --3way, the merged file should be tagged using the encoding specified by:
zos-working-tree-encoding
or
working-tree-encoding
in .gitattributes.
Example:
*.c zos-working-tree-encoding=ibm-1047
The resulting merged file should be tagged as IBM-1047.
Actual Behavior
The merged file content is converted correctly, but the file tag is incorrect. Users currently need to manually retag files
On z/OS, git apply --3way correctly converts file content according to the configured zos-working-tree-encoding / working-tree-encoding attribute, but fails to apply the expected file tag to the resulting merged file.
The merged file content is correct, however the file tag falls back to the default system tag (typically ISO8859-1/UTF-8) instead of the encoding specified in .gitattributes.
This issue appears specific to the --3way merge path.
Expected Behavior
After git apply --3way, the merged file should be tagged using the encoding specified by:
zos-working-tree-encoding
or
working-tree-encoding
in .gitattributes.
Example:
*.c zos-working-tree-encoding=ibm-1047
The resulting merged file should be tagged as IBM-1047.
Actual Behavior
The merged file content is converted correctly, but the file tag is incorrect. Users currently need to manually retag files