The first beta release of z/OS git has been out for five weeks now and has proved extremely stable. Only two bugs reported with about a dozen users. The second beta adds support for git archive facility and the perl-dependent features such as interactive command options. The second beta is now in internal test and will be available in 5 to 10 days. Reply to this post if you are interested in trying out git for z/OS.
Best,
-Peter

Hi Peter,

Add me to the list to test git on z/OS.

Tim

Yes, interested in trying out git for z/OS

Very interested in trying out the z/OS port of Git.

I would love to try this out as well!

z/OS git is now ready for serious use. There are some known limitations documented in the README file but these relate only to uncommon use cases. Both the README and Release Notes are required reading if you want to use this release. If you need to use these uncommon use cases, you may want to wait for the second beta release which is due for release in five to ten days. I will notify you when it is released in any case.

Please use the following links to download the release. All of these parts are required with the exception of gzip for those that already have it.

README.txt
Release Notes
Bash 4.3
Perl 5.24 <== Only to satisfy dependencies. Not yet for general use
Git 2.3.5
gzip 1.6 EDC

Is HTTPS not supported right now? I can’t download from github, which is my primary use case.

DOC:/u/doc/junix: >git clone https://github.com/kohlschutter/junixsocket.git
Cloning into ‘junixsocket’…
fatal: Unable to find remote helper for ‘https’

I re-read the doc and I see “The only remote protocol supported is ssh”. Are there plans to support other protocols? git uses libcurl for HTTPS so it should be doable.

github supports the ssh protocol, and cloning github repos via ssh from z/OS works fine. This does require you to create an account on github and set up an ssh key pair.

git functionality on z/OS will improve over time, but I don’t know if or when additional protocols will be supported.

Does that apply to cloning public repositories?

Yes, public repos on github may be cloned using the ssh protocol, once you have set up an account and a key pair.

Thanks. I haven’t explored that yet as I’ve just simply used git on z/OS from a windows shell using HTTPS and SMB. But this port looks promising as it supports file tagging.

I’ve got an issue with the .gitattributes processing.

My C++ code is all in IBM-1047. I’ve created the following .gitattributes file.

Makefile working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.c      working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.cpp    working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.h      working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.hpp    working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.md     working-tree-encoding=ibm-1047 git-encoding=iso8859-1

I do a “git init” and a “git add .”. The “git add .” has tagged all my source files as ISO8859-1

DOC:/u/products/txc110/cprof/cpp: >ls  -alT src
total 7840
                    drwxr-xr-x   2 DOC      INTERNAL    8192 Nov 23 14:54 .
                    drwxr-xr-x   6 DOC      INTERNAL    8192 Nov 23 20:36 ..
t ISO8859-1   T=on  -rw-rw-rw-   1 DOC      INTERNAL    5237 Nov 23 14:37 connection.cpp
t ISO8859-1   T=on  -rw-r--r--   1 DOC      INTERNAL 2654807 Nov 23 14:38 connection.lst
- untagged    T=off -rw-r--r--   1 DOC      INTERNAL  410400 Nov 23 14:38 connection.o
t ISO8859-1   T=on  -rw-rw-rw-   1 DOC      INTERNAL    6802 Nov 18 10:33 native_connection.cpp
t ISO8859-1   T=on  -rw-r--r--   1 DOC      INTERNAL  748911 Nov 18 10:33 native_connection.lst
- untagged    T=off -rw-r--r--   1 DOC      INTERNAL  107760 Nov 18 10:33 native_connection.o

Interestingly “git check-attr -a *” shows that only the Makefiles show up as attributes. The file patterns have been ignored.

DOC:/u/products/txc110/cprof/cpp: >git check-attr -a *
Makefile: working-tree-encoding: ibm-1047
Makefile: git-encoding: iso8859-1

Am I missing a trick here?

This is currently a bit tricky, and not working the way we want it to work in the long run.

First off: the .gitattributes file MUST be encoded and tagged as iso8859-1. This is mentioned in the release notes PDF, but it’s probably easy to overlook.

Second: tags are set to match the attributes only on checkout. I’m not sure why git add is setting the tags to iso8859-1; it shouldn’t be.

Third: attributes will only be honored once they are committed to the repo, so you want to commit the .gitattributes file first.

Here’s a log of the steps I used to get to a good tree.

bash-2.03$ ls -alT
total 96
                    drwxr-xr-x   2 TSJLC    PDUSER      8192 Nov 23 09:49 .
                    drwxr-xr-x  59 TSJLC    PDUSER     28672 Nov 23 09:49 ..
- untagged    T=off -rw-r--r--   1 TSJLC    PDUSER        13 Nov 23 09:49 Makefile
- untagged    T=off -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 09:47 foo.c
- untagged    T=off -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 09:47 foo.h
bash-2.03$ touch .gitattributes
bash-2.03$ chtag -tc819 .gitattributes

  <Edit .gitattrbutes here>

bash-2.03$ head -9999 * .gitattributes
==> Makefile <==
# Some rules

==> foo.c <==
// Some .c file

==> foo.h <==
// Some .h file

==> .gitattributes <==
Makefile working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.c      working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.cpp    working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.h      working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.hpp    working-tree-encoding=ibm-1047 git-encoding=iso8859-1
*.md     working-tree-encoding=ibm-1047 git-encoding=iso8859-1
bash-2.03$ git init .
Initialized empty Git repository in /u/tsjlc/gt/.git/
bash-2.03$ bash-2.03$ git add .gitattributes
bash-2.03$ git commit -m "commit .gitattributes before other files"
[master (root-commit) 4b0a252] commit .gitattributes before other files
 1 file changed, 6 insertions(+)
 create mode 100644 .gitattributes
bash-2.03$ ls -alT
total 120
                    drwxr-xr-x   3 TSJLC    PDUSER      8192 Nov 23 09:53 .
                    drwxr-xr-x  59 TSJLC    PDUSER     28672 Nov 23 09:52 ..
                    drwxr-xr-x   8 TSJLC    PDUSER      8192 Nov 23 09:53 .git
t ISO8859-1   T=on  -rw-r--r--   1 TSJLC    PDUSER       378 Nov 23 09:50 .gitattributes
- untagged    T=off -rw-r--r--   1 TSJLC    PDUSER        13 Nov 23 09:49 Makefile
- untagged    T=off -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 09:47 foo.c
- untagged    T=off -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 09:47 foo.h
bash-2.03$ bash-2.03$ git add foo* Makefile
bash-2.03$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Makefile
    new file:   foo.c
    new file:   foo.h

bash-2.03$ ls -alT
total 120
                    drwxr-xr-x   3 TSJLC    PDUSER      8192 Nov 23 09:53 .
                    drwxr-xr-x  59 TSJLC    PDUSER     28672 Nov 23 09:52 ..
                    drwxr-xr-x   8 TSJLC    PDUSER      8192 Nov 23 09:55 .git
t ISO8859-1   T=on  -rw-r--r--   1 TSJLC    PDUSER       378 Nov 23 09:50 .gitattributes
t ISO8859-1   T=on  -rw-r--r--   1 TSJLC    PDUSER        13 Nov 23 09:49 Makefile
t ISO8859-1   T=on  -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 09:47 foo.c
t ISO8859-1   T=on  -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 09:47 foo.h
bash-2.03$ git commit -m "add the other source files"
git commit -m "add the other source files"
[master c5f24f6] add the other source files
 3 files changed, 3 insertions(+)
 create mode 100644 Makefile
 create mode 100644 foo.c
 create mode 100644 foo.h
bash-2.03$ bash-2.03$ rm Makefile foo*
bash-2.03$ git checkout -f --
bash-2.03$ ls -alT
ls -alT
total 120
                    drwxr-xr-x   3 TSJLC    PDUSER      8192 Nov 23 10:00 .
                    drwxr-xr-x  59 TSJLC    PDUSER     28672 Nov 23 09:52 ..
                    drwxr-xr-x   8 TSJLC    PDUSER      8192 Nov 23 10:00 .git
t ISO8859-1   T=on  -rw-r--r--   1 TSJLC    PDUSER       378 Nov 23 09:50 .gitattributes
t IBM-1047    T=on  -rw-r--r--   1 TSJLC    PDUSER        13 Nov 23 10:00 Makefile
t IBM-1047    T=on  -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 10:00 foo.c
t IBM-1047    T=on  -rw-r--r--   1 TSJLC    PDUSER        16 Nov 23 10:00 foo.h
bash-2.03$ git check-attr -a *
Makefile: working-tree-encoding: ibm-1047
Makefile: git-encoding: iso8859-1
foo.c: working-tree-encoding: ibm-1047
foo.c: git-encoding: iso8859-1
foo.h: working-tree-encoding: ibm-1047
foo.h: git-encoding: iso8859-1
bash-2.03$

I know - that “rm” step is ugly. Another way to do this would be to do the first two commits (for the .gitattributes file and the source), then copy the .git directory to a new directory and do a git checkout to check out the source (and have it correctly tagged).

Note that, once you have the repo up and running, you will rarely have to fiddle with the attributes; it all just works.

Thanks for testing this, and I hope this helps.

– Jerry

Thanks Jerry, that worked a treat! Obviously you’ve got a few bugs to iron out but once the initial setup is done it works great.

IMO, this z/OS git port is the most significant and eagerly anticipated port for many years. Well done and many thanks.

I am a COBOL developer and would love to use this as our source code control. I’ve had a lot of luck so far. One issue is that because all of our source code copybooks are currently PDS/E members, and of course do not have a file extension, all of our COPY statements of course do not have the extension. Therefore if we move the source to the Unix filesystem we still need things like “COPY ‘MYCOPY’.” to work. That means we have to keep the file names the same, and not add an extension like .CPY or .COB.

Which leads to a question about .gitattributes. It looks like you can name a fully qualified file name (like Makefile in the previous example) and you can name a wildcard with an extension (*.c, *.h, etc.). But can you do simply the wildcard (perhaps just *)? I’ve tried it and I can’t seem to make it work.

Another question about .gitattributes: Does it truly only currently support one EBCDIC codepage, ibm-1047? All of our COBOL source code is in 1140 (037 with the euro; not that we use the euro!). While we don’t have many instances of using the left and right brackets (’[’ ‘]’), we do have a few. And our COBOL compiler is set for CCSID 1140 as well. Am I out of luck in this regard?

Thanks!
Frank

Hi Frank,
I will get you an answer regarding wildcard by tomorrow. Regarding other EBCDIC code page support, you are out of luck for now. We may add support for more code pages to the extent that there are mappings with UTF-8 but this work would have to compete with other demands. Note that paid support is available and paying customers do get priority over non-paying customers regarding wish lists.
Best Regards,
-Peter

Frank,

Are you planning to actually use z/OS UNIX to compile your COBOL code?

If not you may consider writing a script which stages your COBOL source code in a UNIX directory and use “iconv” to convert them from IBM-037 to IBM-1047. Then use git to add/commit/push.

copy PDS to UNIX directory

cp -U “//‘COBOL.SOURCE’” .

convert codepage from IBM-037 to IBM-1047

for i in *; do; iconv -f ibm-037 -t ibm-1047 $i > $i.e; mv $i.e $i; done

What would be a game changer is mouting PDS data sets to UNIX filesystems. IIRC, this may be possible by writing a physical file system that maps PDS data sets to unix files.

can you do simply the wildcard (perhaps just *)?
The problem is that the .gitattributes file itself must be encoded ISO8859-1. So simple wild card may work if the encoding specified is ISO8859-1 but that does not help you.

Does it truly only currently support one EBCDIC codepage, ibm-1047?
In fact, other encoding (e.g. IBM-1140) can be specified in attributes files. However due to the fact that there is no complete bi-direction mapping between EBCDIC and UTF-8, use of some special characters may cause problems and this is an unsolvable problem you will need to work around.

Rocket is happy to announce another beta release of z/OS git 2.3.5. The final GA release will follow in two weeks. This note describes the content of both releases.

Problems solved in the beta 2 release:

• git interactive mode errors
• git -p mode errors
• git archive command

If you want the beta 2 release, here are the download URLs:

git 2.3.5
bash 4.3
perl 5.24
unzip 6.0
gzip 1.6
README.ZOS
Release notes for Git 2.3.5 for zOS.pdf

Bugs to be fixed in GA:

• Problems creating and applying patches with EBCDIC

Features to be added for GA:

• Add support for binary file types in git-attributes file
• git add should check consistency of file tags against configuration settings

When you (pfandel) say “there is no complete bi-direction mapping between EBCDIC and UTF-8” I would say that is true, but is more accurately stated that “not every UTF-8 character can be mapped to a valid EBCDIC code page”.

But in my case this does not really matter. All that matters is that each character in the EBCDIC code page I am using (1140) does have a corresponding UTF-8 value. So unless I were to edit the UTF-8 representation of the file to include a character that cannot be mapped to IBM-1140 (and why would I do that?), it all seems to work just fine.

I did some more testing and I have found no issues with using CCSID 1140 rather than 1047, as long as the git-encoding codepage has a valid mapping for each EBCDIC symbol being used. Is this “only coincidentally” working?

I created a repository on Github with some tests that seem to prove that this works. You can find it here: https://github.com/fswarbrick/codepage_test.git.

Frank

The following appears to do what I want:
[A-Z]* working-tree-encoding=ibm-1140 git-encoding=iso8859-1

This says (hopefully) to match any file starting with a capital letter and not having an extension.

Someone please correct me that that sounds wrong, but it seems to work.