GIT 2.26 "git status" performance issues

In my time using git I've found one of the quickest executing commands is "git status". It gets issued a lot but response times always seems instantaneous, until 2.26.   The first time this was issued after the conversion from 2.14 to 2.26 it took a long time to complete, I'm talking 30+ seconds, which is a lot when you were expecting instantaneous. 

There was a line in the 2.26.2 for z/OS release notes that said:

When you clone the repository with Git for z/OS 2.26.2, you need to run git status command. You might see that Git marks some files with the attribute as modified, even if you didn't modify them.

Now I'm assuming this first "git status" after the upgrade took a long time because it needed to scan the repo to look at the attributes.  I say this because after the first "git status" the second execution was back to being instantaneous again.  But...

The long "git status" response times have reappeared.  From my investigation it seems to happen when a large number of files are transferred from z/OS datasets down to USS.  The first "git status" after the transfer results in a long response time, the second and subsequent commands are back to normal, until a large amount of files are transferred to USS again. 

This did not occur using 2.14.

Has anyone else seen this behavior ?


------------------------------
Gary Freestone
Systems Programmer
Kyndryl Inc
Mt Helen VIC AU
------------------------------

Hello,

We had (still have) the same issue. I can give the conclusion we came to based on the behavior we observed. I just want to emphasize that we haven't taken the time confirm our conclusion but the explanation fits in our case.

When git status is run, git needs to identify all files in the working tree that have changed. This requires "looking" at every file in the working tree (minus ignored and untracked files). Git will first look at the ctime and/or mtime of the file (in our case we were interested in ctime). If ctime/mtime is older than what is in the index, then nothing more needs to be done.

If the ctime/mtime is newer than the timestamp git has indexed, then the file contents need to be compared. This requires unpacking the internal version and possibly converting it to EBCDIC, then comparing the internal version with the file in the working directory, which requires reading both versions of the files. If there many of files, or if the files are big, then this can take a long time.

In our case, we were running chmod on all files in the repository to ensure the correct permissions. This operation changed the ctime for all files in the working directory, which then forced git to do the unpack/convert/compare operations on all files. Our fix was to not run chmod on all the files, and since then, everything is running fast. 

If you are unfamiliar with ctime/mtime, then the following is a quick explanation. mtime is a timestamp that is part of the metadata of a file that denotes the last time a file was change. ctime is a timestamp that is part of the metadata of a file that denotes the last time the metadata of a file was changed (permissions, owner, group etc.)

You can see these timestamps with the "stat" command, fx 'stat file.txt'

------------------------------
Adam Martin Britt
IT-Architect
BEC
Randers SV DK
------------------------------