Add support for z/OS codepage encodings

[IgorTodorovskiIBM]

According to Rocket’s Git 2.26.2 release notes

It seems that the only supported attribute in .gitattributes is zos-working-tree-encoding.

zos-working-tree-encoding: the character encoding of files stored in the working directory. These files are the reason Git exists. They are the user-defined content of the repository, and are what the user edits and compiles. This encoding is controlled via the Git attributes system

It also turns out that the git-encoding attribute is redundant and no longer needed:

git-encoding attribute is no longer used in Git for z/OS 2.26.2 Git 2.26.2 ignores git-encoding attribute and encodes the content from the specified encoding to UTF-8. To avoid misunderstanding it is recommended to remove all git-encoding attributes from .gitattributes.

Additionally, the attribute we're using, working-tree-encoding, conflicts with the attribute of the same name that Git upstream added. it is no longer recommended due to the following reason:

Release 2.18 of the platform-generic git code introduced a git attribute with the same name (working-tree-encoding) as the one used by the Rocket z/OS port of release 2.3.5. The meaning is essentially the same; however, this means that attempts to use a repository prepared on z/OS with other open source platforms (such as Windows, or the servers that typically run git servers such as GitHub or BitBucket) will now attempt to process this attribute, almost certainly with undesired results. It was considered unlikely that this attribute would ever appear in the platform generic git; this turned out to be wrong.

---

So, we could continue to go along with Rocket's approach (use zos-working-tree-encoding) or come up with our own approach that is a bit more generalized.

My take:

Given that "working-tree-encoding" is already supported by the latest versions of Git, and the only issue with it being that we want the encodings to apply to our platform, z/OS, I am thinking that we could add an OS or platform flag to filter where the working-tree-encoding attribute should apply. This flag would be similar to the eol flag documented here: https://git-scm.com/docs/gitattributes

For example:

*	text working-tree-encoding=IBM-1047 os=zos

And not specifying the os filter would mean that

*	text working-tree-encoding=IBM-1047

would apply to all platforms.

[IgorTodorovskiIBM]

If a user wants attributes to apply globally, they can define them in their $HOME/.config/git/attributes path or override this path with the core.attributesFile setting.

[MikeFultonDev]

makes sense to me. this would be good to discuss at the next guild call

[IgorTodorovskiIBM]

Created PR: #22

[phaumer]

As most users will be coming from Rocket Git I would recommend keeping support for zos-working-tree-encoding to ease migration. A clone command could print a deprecation warning pointing people to the new format.

[ccw-1]

I would like to have an option (preferably an environment variable) to totally ignoring file tags and make git works exactly like it is on non-filetag platforms.

[IgorTodorovskiIBM]

PR for platform-working-tree-encoding in #23 (On z/OS, platform gets substituted with zos). This should make it compatible with Rocket's git.

[MikeFultonDev]

@ccw-1 @IgorTodorovskiIBM what is more git-like - to use an env var or a config setting? For config, it could then be local or global?

[IgorTodorovskiIBM]

We could probably add a new git config setting like core.ignoretags, which defaults to false, but can be set to true. And then we can leverage the local/global capabilities of git-config as you mentioned Mike.

[ccw-1]

Yes, core.ignoretags is a good idea. then it can be set on a per repository basis.

[MikeFultonDev]

So I understand, if someone had provided a .gitattributes file with encodings, those encodings would still be processed correct? The core.ignoretags would just be for 'unspecified' files not covered with 'working-tree-encoding'?
If so, I'm wondering if we could tweak this to something like:

core.defaulttag

and have the 'default' be ISO8859-1 but one could specify:

• none: which would provide @ccw-1 's behaviour
• ISO8859-1: same as default
• IBM-1047: tag files as American EBCDIC - handy for COBOL and PL/I developers
• xxx: tag files as whatever is specified (e.g. perhaps 037)

[MikeFultonDev]

This is done. @IgorTodorovskiIBM if not, please re-open