Products Resources Support About Us

Fatal message when adding a file to stage using a local repo

I’d like to run git in code page IBM-1047 or let it default.
It looks like git is configured to use ISO8859-1.

How can I change it so that I don’t have to use tagging, auto convert, etc.?

Here are the commands I used:

git --version
git version 2.3.5_os390_b013

cd local-repo
created a file using vi testfilez

ls -al
drwxr-xr-x 8 XXXXXX YYYYYYYY 8192 Aug 21 13:35 .git
-rw-r–r-- 1 XXXXXX YYYYYYYY 0 Aug 21 12:14 .gitignore
-rw-r–r-- 1 XXXXXX YYYYYYYY 6 Aug 21 14:02 testfilez

chtag -p testfilez
m IBM-1047 T=off testfilez

git add testfilez
fatal: testfilez added file : file tag (IBM-1047) does not match file attributes (ISO8859-1)

git status
On branch master
Untracked files:
(use “git add …” to include in what will be committed)


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



I recommend you to read zOS_Git_Release_Notes.pdf, which describes how to use this git port. You can find this file in /share/doc/git/2.3.5 or immediately in RocketCommunity.
According to your question. We port products with enhanced ASCII support, so it is not possible to use them without tagging and auto convert.

If you are sure all files in your repository are in EBCDIC encoding, you have to create .gitattributes file and add following settings:

∗ working-tree-encoding=ibm-1047 git-encoding=iso8859-1
.gitattributes working-tree-encoding=iso8859-1 git-encoding=iso8859-1
.gitignore working-tree-encoding=iso8859-1 git-encoding=iso8859-1

.gitattributes and .gitignore should be in ISO8859-1 encoding and have the same tag.

1 Like

You might also want to read this forum post regarding using git on z/OS with github for examples of working with EBCDIC files.

Followed the Git for z/OS Release Notes PDF for installation and configuration.
We’re running z/OS 2.2, and have a USS file system mounted on directory /ourxxx/hrobuild with tagging (TEXT,819).

XXJAVA@SYSX$ git --version
git version 2.3.5_os390_b013

I’m working with an application developer who is running into a couple of issues.
After running a successful git clone using ssh, the git pull is failing.
/ourxxx/rocket/git-2.3.5/libexec/git-core/git-pull: cd: ÅÑÈŽ: EDC5129I No such file or directory.

These are the commands that were used.


XXJAVA@SYSX$ git clone ssh://
Cloning into ‘hroexception’…
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 24 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (24/24), 4.20 KiB | 0 bytes/s, done.
Checking connectivity… done.

XXJAVA@SYSX$ cd hroexception

XXJAVA@SYSX$ git status
On branch master
Your branch is up-to-date with ‘origin/master’.
nothing to commit, working directory clean

XXJAVA@SYSX$ git pull
/ourxxx/rocket/git-2.3.5/libexec/git-core/git-pull: cd: ÅÑÈŽ: EDC5129I No such file or directory.
Unable to determine absolute path of git directory

XXJAVA@SYSX$ git pull origin master
/ourxxx/rocket/git-2.3.5/libexec/git-core/git-pull: cd: ÅÑÈŽ: EDC5129I No such file or directory.
Unable to determine absolute path of git directory

XXJAVA@SYSX$ git check-attr -a *

XXJAVA@SYSX$ cat .git/info/attributes

  • git-encoding=ISO8859-1 working-tree-encoding=ISO8859-1

Is there a way to trace what is occurring?

This problem looks very similar to the one reported here.

Did you install the co-requisite products of bash 4.3 and perl, and are you using that bash as your shell?

As for tracing: You can set GIT_TRACE=1 and GIT_TRACE_PACK_ACCESS=1 to get more information.

We have bash 4.3 and perl 5.24 installed.
The user just added the bash profile to his .profile and re-logged in.
That worked. Thank you.

XXJAVA@SYSX$ git pull origin master
From ssh://

  • branch master -> FETCH_HEAD
    Already up-to-date.

XXJAVA@SYSX$ git pull
Already up-to-date.

Our USS default shell is /bin/sh and when we log in we source “profiles” using dot scripts in .profile.
Do we need a .bashrc file too?


. /hewitt/rocket/perl/perl.profile
. /hewitt/rocket/git/git.profile
. /hewitt/rocket/bash/bash.profile

Great that it worked!

There are many possible ways to configure the shell startup files, and I can’t really say that there is any particular standard or best practice. Many users prefer to control the shell startup process entirely.