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

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

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

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

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

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’

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’

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.

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

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

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

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

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

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

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

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

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