DSFS & Git

[v1gnesh]

For git-tracking PDS/PDSE files via DSFS, the following things need to be solved:

• member names starting in .
• member names >8 chars

Some starting points:

• Duplicate PDS/PDSE content into zFS files (transparently), and let git manage the zFS instead. Sync b/w the two needs to be figured out.
• Upstream platform-specific workarounds for the member name constraints
• Add workarounds into DSFS

Let's say we have

/user1/pds
/user1/pdse
/user1/psfile

/user1/pds & /user1/pdse themselves may be git-tracked directories, so they're dealt with separately.
/user1/psfile and any other psfiles in user1 all need to be git-tracked at the /user1/ (HLQ path, in DSFS terms) or above level.

There are 2 parts to a git-tracked dir/project -

• source dir / working tree
• git directory (.git)

Git documentation suggests that

• git dir can be placed elsewhere
• .gitignore can be placed elsewhere
• .gitattributes can be placed elsewhere

Thought:
Replace .git dir with a .git file, which says gitdir: <path-to-zFS-where-no-pdspdse-constraints-exist>
This means we can keep source dir in PDS/PDSE, and git dir in zFS files.
It might help to reserve a namespace (ex: /git/) in zOS, solely to host git dirs in zFS files.
They can all go in a giant "zOS-managed" zFS file, or can be individual zFS files based on HLQ path.

Example:
A PDS/PDSE called MANGO.WHATEVER will be the source dir.
It will have a member named <git which has the content - gitdir: /git/mango/whatever.
gitattributes, gitignore, etc. will be within the gitdir.
Either upstream git could accept <git as the file name for zOS, or it has to be implemented in DSFS.

A vague, half-formed thought... would Union File Systems help here with something?
/mango/whatever being a UFS 'root', where
/mango/whatever/ is served by DSFS, and
/mango/whatever/.git is served by a zFS.

And just as an option, since direnv can automatically set or unset env. variables, or run scripts upon stepping into or out of directories, this capability may be handy, if we're able to effectively use some of the vars available in git's source code (examples in reference below).

Gotcha:
Workaround for the existence of the .git file alone needs to be added either into DSFS or PDS/PDSE.
When accessing git-tracked PDS/PDSE (find an identification method), DSFS could translate .git to <git, or some other reserved member-name prefix... support for which needs to be added into PDS/PDSE.
Since the first char can be $ or ¢, I'm assuming something like < will work.
If setting up support for a . or a < prefix is the same work anyway, I'm just rambling then.. 😛

Reference:

https://stackoverflow.com/a/67501784

.gitignore
$XDG_CONFIG_HOME/git/ignore > $GIT_DIR/info/exclude > .gitignore
core.excludesFile

.gitattributes
$GIT_DIR/info/attributes > .gitattributes (same dir > parent dirs > global config > system-wide)

system-wide:
default = $(prefix)/etc/gitattributes

global (user-level):
core.attributesFile (default = $XDG_CONFIG_HOME/git/attributes, else $HOME/.config/git/attributes)

repo-level:
$GIT_DIR/info/attributes

There are also variables like this in the code base that might be helpful.

$ETC_GITATTRIBUTES
$GITATTRIBUTES_FILE

Is any of this usable 😅 ?

[lbdyck]

I asked Kershaw a few questions in early June - his answers may lend insight:

Q1. Does DSFS support ISPF statistics for PDS/PDSE members?
A1. Yes. When the data set is closed, the ISPF statistics will be updated.

Q2. Does DSFS support PDSE member generations? Creating, deleting, accessing?
A2. No DSFS doesn’t support GDGs or PDSE member generations currently.

Q3. How does it handle a PDS/PDSE where some members are text and others are binary?
a. The reason some are binary, at least for git and omvs purposes, is that the member contains one of a number of special characters that cause the member to be corrupted if copied (cp) as text. For example, null (x’00’) and carriage return (x’0D’), new line (x’15’), and line feed (x’25’)
A3. Yes. Remember with DSFS, the user needs to know about the contents of the data set or member and needs to use that information when accessing the data set via DSFS. With this in mind and specific to your question, one could access members of a data set KERSHAW.PDSE.GIT as follows:
• /dsfs/txt/kershaw/pdse.git/member1
• /dsfs/bin/kershaw/pdse.git/member2
• /dsfs/rec/kershaw/pdse.git/member3
One just needs to know the consequence of accessing a data set or member as txt or bin or rec.

Q4. How are the ‘files’ tagged? /text would be as text and /bin as binary I presume? What about code page?
a. Thinking for git usage here.
A4. There is no tagging of files. Today, there is no code page tagging support for data sets or members, hence no tagging capability for them via DSFS. Even in the use of /dsfs/txt or /dsfs/bin, there is no tagging.

[v1gnesh]

Thanks for sharing.
4th Q&A makes me wonder... does that mean git-managed PDS/PDSE can only be native (EBCDIC)?

[lbdyck]

that's the way I read it