zosopentools / gitport

Git on z/OS

Git is a popular version control system that is widely used in the open source community.

Pre-requisites

Git on z/OS has the following dependencies:

• bash - https://github.com/ZOSOpenTools/bashport/releases
• perl - https://github.com/ZOSOpenTools/perlport/releases
• less - (default pager) //github.com/ZOSOpenTools/lessport/releases
• ncurses - https://github.com/ZOSOpenTools/ncursesport/releases

Once you set up these dependences, you can then install Git.

Obtaining Git on z/OS

Git on z/OS can be downloaded from https://github.com/ZOSOpenTools/gitport/releases.

If you have curl on your system, you can download the latest version with:

curl -L -o gitport.pax.Z https://pathtogit.pax.Z

You can then extract the pax.Z as follows:

pax -rf gitport.pax.Z
cd git-*

Setting up a CA Certificate

To obtain a CA certificate, you can download the recommended CA certificates extracted from Mozilla here: https://curl.se/docs/caextract.html

If you have zopen in your path, you can use the zopen update-cacerts command to download the latest CA certificate.

Once you have a CA Certificate on your file system, you can set the GIT_SSL_CAINFO environment variable to point to it.

export GIT_SSL_CAINFO=/path/to/my/cacert.pem

Setting up Git on z/OS

Once installed, you will need to source the .env file as follows:

. ./.env

This will set the PATH, LIBPATH, MANPATH and other Git environment variables.

Encoding considerations

Git on z/OS leverages Git's .gitattributes support to enable support for various encodings, documented here. .gitattributes can be specified globally, or locally in repositories to determine the encoding of working tree files.

Working-tree-encoding

The working-tree-encoding attribute can be used to determine the working tree encoding. For example, to convert all files from Git's internal UTF-8 encoding to IBM-1047, you can specify the following working-tree-encoding in your .gitattributes file:

* text working-tree-encoding=IBM-1047

This will result in Git on z/OS tagging all files as IBM-1047 on checkout.

If you want the working-tree-encoding to apply to the host platform only, then you can use: platform-working-tree-encoding where platform is substituted with the system name.

On z/OS, platform is zos. Therefore, the .gitattributes would be:

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

If no encoding is specified, the default UTF-8 encoding is used and all files are tagged as ISO8859-1.

To find out all of the supported encodings by git, run iconv -l.

When adding files, you need to make sure that the z/OS file tag matches the working-tree-encoding. Otherwise, you may encounter an error.

Important Note: If you are relying on the zos-working-tree-encoding support and you are editing your git-managed files on a non-z/OS platform, make sure that the files are encoded in UTF-8 mode. This is because Git assumes such files are encoded in UTF-8 prior to conversion. See the working-tree-encoding documentation for more details. If you insist on editing your files in a different encoding, make sure to add the working-tree-encoding to the .gitattributes to reflect the codepage:

*  zos-working-tree-encoding=ibm-1047 working-tree-encoding=iso8859-1

This indicates that the file will be encoded in IBM-1047 on z/OS, but on non-z/OS platforms, it will be encoded in iso8859-1.

Encodings and z/OS File Tags (CCSIDs)

Note: Git on z/OS now aligns the file tag (CCSID) with the git working-tree-encoding by default. Previously, there was a specific handling for UTF-8 encoded files. These files were tagged as ISO8859-1 (CCSID 819) due to z/OS Open Tools' behavior under _BPXK_AUTOCVT=ON, which doesn't auto-convert files tagged with the UTF-8 tag (CCSID 1208). Consequently, the default tag for UTF-8 encoded files is now UTF-8 (or CCSID 1208).

To adjust the default tag for UTF-8, you can configure the git setting core.utf8ccsid to 819 using the following commands:

• git config --global core.utf8ccsid 819 # Global setting, 819 represents the CCSID for the UTF8 file tag
• git config core.utf8ccsid 819 # Local setting affecting the current repository

Alternatively, you can set the GIT_UTF8_CCSID environment variable:

• export GIT_UTF8_CCSID=819 # Environment variable

The environment variable takes precedence over the git config setting.

Example

Assuming you want to clone UTF-8 encoded files with the tag UTF8 or ccsid 819 as opposed to the default ccsid (1208):

git config --global core.utf8ccsid 819 # Set the UTF-8 ccsid 819 globally
git clone https://github.com/git/git
cd git
ls -lT # you will notice that all files are now tagged as 819

Binary files

To specify a binary encoding, you can use the binary attribute as follows:

*.png binary

This will tag all *.png files as binary.

Untagged files

Git on z/OS does not currently support adding untagged files. Files need to be tagged before they can be added.

Multiple encodings

You can specify multiple working-tree-encoding attributes, where the later attributes overrides the initial attributes in case of an overlap.

* text working-tree-encoding=IBM-1047
*.png binary

Migration considerations

If you are migrating from Rocket Software's Git, then the good news is that Git on z/OS should be compatible.

If you encounter any issues, please open an issue under https://github.com/ZOSOpenTools/gitport/issues.

gitport's Issues

git readme missing info

Some info missing from the readme.md is:

1. What pre-req/co-req tools are required for git
2. how to download and install if only git and req's are desired
3. simple how to install and configure for production use

Remove - and validate - setting environment variables in shell for git

In buildenv we should only need to set the environment variables on in the binary (e.g. keep zopen_append_to_zoslib_env and remove zopen_append_to_env)

git cannot process untagged files if they are opened with fopen

When files such as .git/config are untagged, git cannot process them. This is because for some reason, fopen automatically changes the ccsid of such files to 1047. This can be overridden by the environment variables _BPXK_CCSIDS, but it can also affect other tooling.

I think a better solution is to override fopen similar to how we override open so that they both handle autoconversion using the same logic.

Gitport "Can't locate strict.pm"

Although PERL is installed on the z/OS system (running zopen list confirms this), I am still unable to build Gitport because it is unable to locate the strict.pm in @inc. I worked with another IBM person to attempt to reconfigure PERL again before rebuilding and that did not work either. The IBM person that I talked to mentioned that it may have something to do with CPAN, but I am unsure.

Default CCSID for tagging

Since zopen sets/recommends _BPXK_AUTOCVT=ON, it seems that GIT_UTF8_CCSID=819 would be used/default as well.
If UTF-8 tagging is needed, then using the variable or
git config commands (git config --global core.utf8ccsid 819 or git config core.utf8ccsid 819) should be used.

Thoughts?

thanks

Unable to specify 'vim' for my editor with the latest git

Hi

I get the following:

FULTONM@ZOSCAN2B bash ~/zopen/dev/bisonport >git config --global core.editor "vim"
FULTONM@ZOSCAN2B bash ~/zopen/dev/bisonport >vi buildenv
FULTONM@ZOSCAN2B bash ~/zopen/dev/bisonport >git add .
FULTONM@ZOSCAN2B bash ~/zopen/dev/bisonport >git commit
hint: Waiting for your editor to close the file... error: cannot run C: EDC5129I No such file or directory.
error: unable to start editor 'C'
Please supply the message using either -m or -F option.
FULTONM@ZOSCAN2B bash ~/zopen/dev/bisonport >git --version
git version 2.39.1
FULTONM@ZOSCAN2B bash ~/zopen/dev/bisonport >type -a vim
vim is /home/fultonm/zopen/boot/vim/bin/vim

files with 'stray' binary values can not be 'added' to a git repo on z/OS

You can see this by doing a 'zopen build' of bashport and you will see that the file array.right is unable to be encoded. It appears to have some stray binary values in the output:

diff array.right array.utf8
312c312
< argv[1] = <�>
---
> argv[1] = <�>
315c315
< argv[3] = <�>
---
> argv[3] = <�>
318c318
< argv[3] = <�>
---
> argv[3] = <�>
321c321
< argv[3] = <�>
---
> argv[3] = <�>

Perhaps this is 'working as designed', but if so, we should likely get the bash repo updated.
A temporary hack is to treat files with a 'right' extension as 'binary' like we do with .jpg an .png

problems with latest git port (git-heads.v2.44.0.20240318_110959.zos)

Hello,

today I updated git from git-2.43.0.20240229_200332.zos to git-heads.v2.44.0.20240318_110959.zos.

After reverting a source code change via git checkout mysource the source file was damaged due to
incorrect new lines. Switching back to the old version of git solved this issue.

(my source file are tagged as IBM-1141)

Regards, Mike

'install' of git fails - needs coreutils 'install' program

make install
    SUBDIR git-gui
    SUBDIR gitk-git
    SUBDIR templates
install -d -m 755 '/u/fultonm/zot/prod/git/bin'
make: install: EDC5129I No such file or directory.
make: *** [Makefile:3189: install] Error 127

Using .gitattributes to encode file as IBM-1047 results in some characters being converted incorrectly

Description

The way I have it set up is that the file is stored as UTF-8 in git, and I'm using .gitattributes to set the working tree encoding to ibm-1047. When cloning the repo, git converts and tags the file as IBM-1047. The issue is that for some characters such as ® (the registered symbol), it appears as ▒ after the conversion.

Reproduce

0. Create a new repository.
1. Create file.txt containing the ® character.
2. Create a .gitattributes file containing either file.txt zos-working-tree-encoding=ibm-1047 git-encoding=iso8859-1 or file.txt working-tree-encoding=ibm-1047
3. Clone the repository.
4. Read file.txt using vim or cat. It will display ▒ instead of ®

Additional info

Upon examination of the file with a hex editor, it appears that it's converting the ® character from C2 AE to AF which results in it being unreadable. Whereas for it to be readable, it would have to be 62 AF.

This is consistent with the behavior when using iconv to convert from UTF-8 to IBM-1047.

Whereas converting from ISO8859-1 to IBM-1047 seems to result in the correct conversion.

git --info-path incorrect

while testing git I ran into a new option the --info-path and thought I'd try it and got this:

/u/jenkins/zopen/prod/git-2.41.0/share/info

The issue is that I do NOT have a /u/jenkins/ directory :)

this is using the latest git revision - updated this morning

Create a test for ebcdic encoded files

To catch such regressions as #106

upgrade failure

when git is first 'set up' on a z/OS system, it should set up the GIT_SSL_CAINFO

There are a few questions.

• Do we want to use this opportunity to update the cacert via zopen update-cacert?
• Do we want to have meta setup copy it's starter cacert.pem up into the boot directory so various tools can use it?

We also need to do this for openssl and curl.

I would like to not keep the cacert in the meta package like we do today because customers that only want our open source tools don't need anything in meta except this cacert file (although they would need it if they wanted to refresh their cacert and didn't want to manually download it with curl.

My opinion:

• No, we don't need to do the zopen update-cacert - it should be sufficient to just tell them of the function and also how to manually download in an info message
• Yes, we should have meta copy it's starter cacert.pem up to boot and we should probably 'hide' it since we don't want people using it (maybe make it .cacert.pem ?). We should update all the tools to not specify a cert but instead use the configured cert that git and curl will have

@IgorTodorovskiIBM would appreciate your thoughts here before I start coding...

Git man pages for build type "git" has to implemented

.gitattributes ignored ???

This is my .gitattributes

# This .gitattributes file is autogenerated with zigi                                                
*                 git-encoding=iso8859-1 zos-working-tree-encoding=ibm-1047 linguist-language=REXX   
ZIGI/PANELS/*     git-encoding=iso8859-1 zos-working-tree-encoding=ibm-1047 linguist-language=PANELS 
.gitattributes    git-encoding=iso8859-1 zos-working-tree-encoding=iso8859-1                         
.gitignore        git-encoding=iso8859-1 zos-working-tree-encoding=iso8859-1                         
*.docm binary                                                                                        
*.docx binary                                                                                        
*.doc  binary                                                                                        
*.pdf  binary                                                                                        
*.epub binary                                                                                        
*.mobi binary                                                                                        
*.azw3 binary                                                                                        
*.pdf binary                                                                                         
ZIGI.PANELS/ZIGIEDIT git-encoding=BINARY zos-working-tree-encoding=BINARY binary           

When I cloned this repoistory the zigiedit was in the filesystem as text and not binary.

this is with git 2.44 - and this same issue with pdsegen:

PDSEGEN.PDS/CLS git-encoding=BINARY zos-working-tree-encoding=BINARY binary

man git yields incorrect results after running mandb

After installing the latest git pax file.
https://github.com/ZOSOpenTools/gitport/releases/download/DEV_gitport_test/git-2.42.1.20231113_233327.zos.pax.Z

mandb warnings attached.
git man results attached.

git-2.42.1_mandb.txt

Git extensions like git-subtree are missing

CW noticed that certain git extensions like git subtree, which are present in the Linux and Mac distributions of Git, are not present in this z/OS version.

There are various extensions in the contrib/ directory of git. They would need to be installed separately. Here's the README for git-subtree:

HOW TO INSTALL git-subtree
==========================

First, build from the top source directory.

Then, in contrib/subtree, run:

  make
  make install
  make install-doc

If you used configure to do the main build the git-subtree build will
pick up those settings.  If not, you will likely have to provide a
value for prefix:

  make prefix=<some dir>
  make prefix=<some dir> install
  make prefix=<some dir> install-doc

To run tests first copy git-subtree to the main build area so the
newly-built git can find it:

  cp git-subtree ../..

Then:

  make test

Pagers do not work with new git - error: cannot run 140: EDC5129I No such file or directory.

git diff
error: cannot run 140: EDC5129I No such file or directory.

Incorrect file tagging ?

On your git (2.39) the file is thus:
t ISO8859-1 T=on -rw-rw-rw- 1 LBDYCK ZOWEDEV 55982 Jan 31 15:03 zginstall.rex
but on git 2.26.2 it is:
t IBM-1047 T=on -rw-rw-rw- 1 SPLBD SYS1 55982 Jan 31 12:05 zginstall.rex
This is the REXX code that ‘extracts’ the file from the git repository
cmd = 'cd' localrep'/'zigirep ,
'&& git show' hcommit':'element ,
'| cat >' file
If I change it thus:
cmd = 'cd' localrep'/'zigirep ,
'&& git show' hcommit':'element ,
'| cat >' file ‘&& chtag -tc IBM-1047’ file
Which does work.
I then get this when I try to edit the file:
The z/OS UNIX file contains a record with a length greater than 32750. Records of this size are not supported by the ISPF editor.
It would seem that ‘git show’ is working differently from the older rocket git.
Bug, Feature, or by design.

git complains about REG_STARTEND on build

with the 'git' build I get the message:

./nohup.out:./git-compat-util.h:1319:2: error: "Git requires REG_STARTEND support. Compile with NO_REGEX=NeedsStartEnd"
./nohup.out:#error "Git requires REG_STARTEND support. Compile with NO_REGEX=NeedsStartEnd"

even though this option is passed via ZOPEN_EXTRA_CPPFLAGS (at least in buildenv).

Need to understand why this is not 'getting through' (maybe bug in zopen-build?)

@dougburns if you have ideas, would love to know - I know you've been working a bit with git

'git' build requires more tools to bootstrap (with a 'git' build, not a 'tarball' build)

Output from bootstrap:

bootstrap: error: Prerequisite 'help2man' not found. Please install it, or
bootstrap: 'export HELP2MAN=/path/to/help2man'.
bootstrap: error: Prerequisite 'makeinfo' not found. Please install it, or
bootstrap: 'export MAKEINFO=/path/to/makeinfo'.
bootstrap: error: Prerequisite 'xz' not found. Please install it, or
bootstrap: 'export XZ=/path/to/xz'.
bootstrap: error: HACKING explains how to obtain these prerequisite programs:
bootstrap: Program Min_version Homepage
bootstrap: -----------------------------------------------------------
bootstrap: help2man 1.29 http://www.gnu.org/s/help2man
bootstrap: make 3.81 http://www.gnu.org/s/make
bootstrap: makeinfo 4.8 http://www.gnu.org/s/texinfo
bootstrap: xz 4.999.8beta http://tukaani.org/xz
bootstrap: autoconf 2.64 http://www.gnu.org/s/autoconf
bootstrap: automake 1.11.1 http://www.gnu.org/s/automake
bootstrap: -----------------------------------------------------------

validate configuration

Go through patch:

gitport/tarballpatches/config.mak.uname.patch

Line 19 in 0f0ae0c

+ifeq ($(uname_S),OS/390)

and make sure these are appropriate and consistent (or a good reason not to be) with the Rocket port

git blame doesn't work on ebcdic files

Hi, please see test repo here with 1 file each: https://github.ibm.com/ecovener/git-example

I am using 2.41.0 on PLPSC, but rocket git fails the same way:

 $ git blame postinst.c |head -c 255
00000000 (Not Committed Yet 2023-07-07 13:23:19 -0400 1) ����ñâ(�ä?>ÃÑÀÁ>ÈÑ/%�|ä|�ë?ÍÊÄÁ�(/ÈÁÊÑ/%����¢��������+����ä��ä|&ßêñåçCOVENER@PLPSC:~/SRC/git-test (main) $
$ git blame README |head -c 255
^76b2371 (Eric Covener 2023-07-07 13:20:40 -0400 1) I am
^76b2371 (Eric Covener 2023-07-07 13:20:40 -0400 2)   Ascii

In case it matters, not a zopen bash:
GNU bash, version 4.2.53(2)-release (i370-ibm-openedition)

.env issues Warning: you need to set GIT_SSL_CAINFO to a pem file if you want to use git with SSH when pem file path has already been specified in .gitconfig

.env issues Warning: you need to set GIT_SSL_CAINFO to a pem file if you want to use git with SSH when pem file path has already been specified in .gitconfig

[http]
    sslVerify = true
    sslCAInfo = /<somewhere>/cacert.pem

Option or environment variable to Ignore file tags

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.

Originally posted by @ccw-1 in #21 (comment)

git production installation and use

It would be nice to have a simple process to:

1. download git and requisite tools
2. install into a common location
3. document/assist in updating the /etc/profile and whatever else

Same for updating an existing installation.

hash error

Description of issue:
If the environment variable GIT_COMMITTER_DATE is set AND GIT_COMMITTER_NAME and/or GIT_COMMITTER_EMAIL is set, the Git committer name and/or email will be replaced with the contents of GIT_COMMITTER_DATE respectively.
Steps to reproduce:
Setup empty repository
mkdir testdir1 && cd testdir1
git init
touch hello
chtag -c819 hello
git add hello
2. Set committer info
export GIT_COMMITTER_NAME='Jane Doe'
export GIT_COMMITTER_EMAIL='[email protected]'
export GIT_COMMITTER_DATE=2019-04-03T13:30:35-04:00
3. Commit and show output
git commit -m 'test commit'
git --no-replace-objects cat-file commit HEAD

ACTUAL OUTPUT

tree f966952d7e0715683ee935d201cd4ab22736c831
author Jane Doe [email protected] 1675113490 -0500
committer Jane Doe [email protected] 1675113490 -0500

test commit

EXPECTED OUTPUT

tree f966952d7e0715683ee935d201cd4ab22736c831
author Jane Doe [email protected] 1675113490 -0500
committer 2019-04-03T13:30:35-04:00 <2019-04-03T13:30:35-04:00> 1554312635 -0400

test commit

git doesnt like https repos

git clone https://github.com/TheMozg/awk-raycaster
Cloning into 'awk-raycaster'...
warning: templates not found /jenkins/workspace/Port-Build/install/share/git-core/templates
fatal: Unable to find remote helper for 'https'

setup.sh changed current directory and corrupt the directory stack

pushd
cd ~opnzos/local/git && . .env;
popd

after sourcing

/home/opnzos/zopen/prod/perl5-blead.20230210_213003.zos ~ /home/opnzos/zopen/prod/ncurses-6.3.20230210_180151.zos /home/opnzos/zopen/prod/less-608.20230203_162213.zos /home/opnzos/zopen/prod/bash-5.2.20230210_170433.zos
/home/opnzos/zopen/prod/perl5-blead.20230210_213003.zos /home/opnzos/zopen/prod/ncurses-6.3.20230210_180151.zos /home/opnzos/zopen/prod/less-608.20230203_162213.zos /home/opnzos/zopen/prod/bash-5.2.20230210_170433.zos ~
 /home/opnzos/zopen/prod/perl5-blead.20230210_213003.zos

pwd 
/home/opnzos/zopen/prod/perl5-blead.20230210_213003.zos

fatal: <file> added file: file tag (UTF-8) does not match working-tree-encoding (ISO8859-1)

*.UTF8 zos-working-tree-encoding=utf-8

bash-5.2$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean

copy as utf-8, tag as utf-8 and git add

bash-5.2$ cp -O c=utf-8 "//'@02858.T.S3TEST.SPECIAL'" zopen_XYZ.special.TXT.UTF8

bash-5.2$ ls -lT zopen_XYZ.special.TXT.UTF8
m UTF-8 T=off -rw-r--r-- 1 @02858 @ISCICS1 20480 Mar 27 09:40 zopen_XYZ.special.TXT.UTF8

bash-5.2$ git add zopen_XYZ.special.TXT.UTF8
fatal: zopen_XYZ.special.TXT.UTF8 added file: file tag (UTF-8) does not match working-tree-encoding (ISO8859-1)

bash-5.2$ chtag -tc UTF-8 zopen_XYZ.special.TXT.UTF8

bash-5.2$ ls -lT zopen_XYZ.special.TXT.UTF8
t UTF-8 T=on -rw-r--r-- 1 @02858 @ISCICS1 20480 Mar 27 09:40 zopen_XYZ.special.TXT.UTF8

bash-5.2$ git add zopen_XYZ.special.TXT.UTF8
fatal: zopen_XYZ.special.TXT.UTF8 added file: file tag (UTF-8) does not match working-tree-encoding (ISO8859-1)

git show for utf-8 characters not correct

echo H¢¬

bash-5.2$ echo -e $'\x48\ua2\uac' > GG.echo

bash-5.2$ ls -lT GG.echo
t ISO8859-1 T=on -rw-r--r-- 1 @02858 @ISCICS1 6 Apr 12 13:56 GG.echo

bash-5.2$ git show HEAD
commit 9aecb13c7735fe7773b32744db541ec12ce16f2f (HEAD -> master, origin/master, origin/HEAD)
Author: Gary Grossi [email protected]
Date: Wed Apr 12 14:03:31 2023 -0500

GG.echo echo -e $'\x48\ua2\uac'

diff --git a/GG.echo b/GG.echo
new file mode 100644
index 0000000..1b59cfc
--- /dev/null
+++ b/GG.echo
@@ -0,0 +1 @@
+H

zopen install git issue

just got this:

/u/lbdyck/zot/boot>zopen install git                                                                 
***WARNING: Run zopen init to configure the install location. Using current working directory...     
Checking git...                                                                                      
New release with tag "Releaseline_gitport_1119" found for gitport                                    
Preparing to download git                                                                            
Downloading latest release from gitport...                                                           
CEE5213S The signal SIGPIPE was received.                                                            
Extracting git-2.41.0.20230705_133135.zos.pax.Z...                                                   
Setting up git...                                                                                    
Setup completed.                                                                                     
Successfully installed git to /u/lbdyck/zot/boot/git/   

and

Checking perl...                                                              
New release with tag "Releaseline_perlport_1060" found for perlport           
Preparing to download perl                                                    
Downloading latest release from perlport...                                   
CEE5213S The signal SIGPIPE was received.                                     
Deleting existing perl5-blead...                                              
Extracting perl5-blead.20230605_161457.zos.pax.Z...                           
Setting up perl5...                                                           

tests failing in git

As of March 1st, 3 tests are failing: https://128.168.139.253:8443/job/Port-Build/1236/artifact/git/log/20230227_144535_check.log

egrep '^not ok' /tmp/out
not ok 45 - subtest: tests clean up after themselves
not ok 46 - subtest: tests clean up even on failures
not ok 47 - subtest: test_atexit is run

man directory and files missing

see subject

protection exception with 'git push' on z/OS

this occurs with a few different versions of git so I don't think it's a regression.
To reproduce:

log in to fultonm@zoscan2b
cd ~/zopen/dev/bashport
git push

This yields:

FULTONM@ZOSCAN2B bash ~/zopen/dev/bashport >git push
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Compressing objects: 100% (4/4), done.
CEE3204S The system detected a protection exception (System Completion Code=0C4).
         From entry point sort_revindex at compile unit offset +0000000026C9A2AE at entry offset +0000000000000296 at address 0000000026C9A2AE.
error: pack-objects died of signal 11
error: pack-objects died of signal 11
error: remote unpack failed: eof before pack header was fully read
To github.com:ZOSOpenTools/bashport.git
 ! [remote rejected] reducefailures -> reducefailures (failed)
error: failed to push some refs to 'github.com:ZOSOpenTools/bashport.git'

The traceback in the CEEDUMP is:

  Traceback:
    DSA   Entry       E  Offset  Statement   Load Mod             Program Unit                   Service  Status
    1     CEEHDSP     +00003FD8              CELQLIB              CEEHDSP                        UI78103  Call
    2     CEEOSIGJ    +00000962              CELQLIB              CEEOSIGJ                       HLE77C0  Call
    3     CELQHROD    +00000266              CELQLIB              CELQHROD                       HLE77C0  Call
    4     CEEOSIGG    -1F111A70              CELQLIB              CEEOSIGG                       UI75815  Call
    5     CELQHROD    +00000266              CELQLIB              CELQHROD                       HLE77C0  Call
    6     sort_revindex
                      +00000296              git                                                          Exception
    7     create_pack_revindex
                      +000002A6              git                                                          Call
    8     load_pack_revindex
                      +00000232              git                                                          Call
    9     offset_to_pack_pos
                      +00000020              git                                                          Call
    10    write_reuse_object
                      +00000256              git                                                          Call
    11    write_object+00000302              git                                                          Call
    12    write_one   +00000196              git                                                          Call
    13    write_pack_file
                      +000003BA              git                                                          Call
    14    cmd_pack_objects
                      +00001C88              git                                                          Call
    15    run_builtin +0000035C              git                                                          Call
    16    handle_builtin
                      +000002AA              git                                                          Call
    17    run_argv    +00000070              git                                                          Call
    18    cmd_main    +00000288              git                                                          Call
    19    main        +00000194              git                                                          Call
    20    CELQINIT    +00001ACA              CELQLIB              CELQINIT                       HLE77C0  Call

Handling of mixed-codepage files in git

We have some mixed-codepage files that are in mostly ibm-1047 but mixed with other codepage such as Japanese.
We can use -text in .gitattributes to check in the files, however using this approach we will lose the ability to do blame/diff the part that are in text (ibm-1047 code).
Perhaps a solution will be to support zos-working-tree-encoding=ibm-1047 -text in .gitattributes?

git clone fails with SHA1SUM

Building git from tarball and then trying to do a git clone of 'meta', I get:

git clone [email protected]:ZOSOpenTools/meta.git
Cloning into 'meta'...
remote: Enumerating objects: 1200, done.        
remote: Counting objects: 100% (210/210), done.        
remote: Compressing objects: 100% (161/161), done.        
remote: Total 1200 (delta 106), reused 100 (delta 47), pack-reused 990        
Receiving objects: 100% (1200/1200), 1.44 MiB | 508.00 KiB/s, done.
fatal: pack is corrupted (SHA1 mismatch)
fatal: index-pack failed

git log issue (2.40 and 2.41)

using command git log --cc -m -n 3

Notice the diff is missing :(

with 2.26

With 2.41.0 (and with 2.40.1)

Out of memory when pager is set to cat

[ITODORO@ZOSCAN2B ~/projects/ibm_meta]$ export GIT_PAGER=cat
[ITODORO@ZOSCAN2B ~/projects/ibm_meta]$ git status
fatal: Out of memory, strdup failed

CEE3501S : CXXRT64 not found

Heya,

Trying to install this on my ZPDT, but hit the brick wall as shown below

IBMUSER:/prj/zotgit/git: >. ./.env
CEE3501S The module CXXRT64 was not found.
         The traceback information could not be determined.
[1] + Done(137) . ./.env
  33620127      Killed  -sh
CEE3501S The module CXXRT64 was not found.
         The traceback information could not be determined.
[1] + Done(137) . ./.env
  50397343      Killed  -sh

It seems ibmruntimes/node#128 looks familiar..... any chance I might need said PTF? How to get it?

Residual files ????

After doing a git clone I'm seeing these files - all empty - in my home directory - with git version 2.44

git 2.44.0 git-heads.v2.44.0.20240318_110959.zos STABLE

Add support for z/OS codepage encodings

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.

git does not resolve $SYSNAME in paths

git clone <somerepo> /tmp/igor
fatal: Invalid path '/$SYSNAME': EDC5129I No such file or directory.

ls -l / | grep tmp
lrwxrwxrwx   1 ROOT     1             12 Nov 11  2021 tmp -> $SYSNAME/tmp

.gitignore seems to ignore files which are untagged

I'm not sure but this seems like an error with tagging

contents of .gitignore

$ cat .gitinore
fibonacci.o
fibonacci

result of git status

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	fibonacci

nothing added to commit but untracked files present (use "git add" to track)

Version of git

$ git -v
git version 2.39.1

Tag status

$ chtag -p fibonacci
- untagged    T=off fibonacci
xxxx@xxx asm (main)
$ file fibonacci
fibonacci:	z/OS Unix executable (amode=31)

Add python as a dependency in buildenv

Currently, if python is not detected, it will skip it:

t/lib-git-p4.sh:        skip_all='skipping git p4 tests; python not available'

git submodule init doesn't seem to work

Running m4 'git' build, I get:

Cloning into 'gnulib'...
Updating files: 100% (10666/10666), done.
trap: func_require_gnulib_submodule 38: func_require_gnulib_tool 5: func_gnulib_tool 4: func_reconfigure 40: func_bootstrap 19: ./bootstrap 5420: FSUM7327 signal number 13 not conventional
bootstrap: running: git submodule init -- gnulib
fatal: 'submodule' appears to be a git command, but we were not
able to execute it. Maybe git-submodule is broken?
bootstrap: running: git submodule update -- gnulib
fatal: 'submodule' appears to be a git command, but we were not
able to execute it. Maybe git-submodule is broken?

Properly support UTF-8 files

Setting a file loaded from git with .gitattributes zos-working-tree-encoding=utf-8 results in a file that is tagged ISO8859-1

This cause trouble for programs that read the file tag and assume some conversion is needed.

Inside of git, all files are UTF-8, and so in the file system setting zos-working-tree-encoding=utf-8 should result in no encoding changes.

Files tagged zos-working-tree-encoding=utf-8 should result in a UTF-8 tag and the file not being re-encoded.