Hi Everyone, Am working on porting git to z/OS. For reference, the pull request am working on https://github.com/git/git/pull/1537. On z/OS there is a notion of file tag attributes. Files can be tagged as binary, ASCII, UTF8, EBCDIC, etc. z/OS uses these attributes to determine if auto-conversion is necessary. It was recommended in PR that we add logic directly to xopen . In order for me to do this in xopen , I have to pass an extra parameter to xopen that specifies the file type. Ex: xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666); To : xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666, BINARY); BINARY: would be an enum value. Would this be okay to do? Or are there other recommendations? Best regards Haritha
threads / discuss / 60606
Propose a change in open for passing in the file type.
Subject: Propose a change in open for passing in the file type.
Re: Propose a change in open for passing in the file type.
On Tue, Dec 12, 2023 at 02:46:04PM +0000, Haritha D wrote:
Show 15 quoted lines
> Hi Everyone, > > Am working on porting git to z/OS. For reference, the pull request am working on https://github.com/git/git/pull/1537. > > On z/OS there is a notion of file tag attributes. Files can be tagged as binary, ASCII, UTF8, EBCDIC, etc. z/OS uses these attributes to determine if auto-conversion is necessary. It was recommended in PR that we add logic directly to xopen . In order for me to do this in xopen , I have to pass an extra parameter to xopen that specifies the file type. > > Ex: > xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666); > > To : > xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666, BINARY); > > BINARY: would be an enum value. > > Would this be okay to do? Or are there other recommendations?
I think that the suggestion was to embedd the BINARY thing into xopen(), not to all callers of xopen().
If you have this type of special handling for one specific OS, call it quirks, if you want, they are better placed in an own file.
Please see e.g. compat/mingw.c as an example, how things are solved for Git for windows. Then there are some include files, which re-define things like open(), if needed.
Another example could be compat/win32/dirent.c
Where exactly things are placed, is may be a matter of taste, that may be decided later. In your case a file like compat/z_os.c and z_os.h may make clear what this is about to everybody.
Show 5 quoted lines
> > Best regards > Haritha > >
Re: Propose a change in open for passing in the file type.
On 2023-12-12 14:46:04+0000, Haritha D <Harithamma.D@ibm.com> wrote:
Show 18 quoted lines
> Hi Everyone, > > Am working on porting git to z/OS. For reference, the pull request am working on https://github.com/git/git/pull/1537. > > On z/OS there is a notion of file tag attributes. Files can be > tagged as binary, ASCII, UTF8, EBCDIC, etc. z/OS uses these > attributes to determine if auto-conversion is necessary. It was > recommended in PR that we add logic directly to xopen . In order for > me to do this in xopen , I have to pass an extra parameter to xopen > that specifies the file type. > > Ex: > xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666); > > To : > xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666, BINARY); > > BINARY: would be an enum value.
Would it work if you always open the file as BINARY? And let's all the conversion done by git via some configs (core.encoding?)?
-- Danh
Re: Propose a change in open for passing in the file type.
On Wed, Dec 13, 2023 at 11:17:17AM +0700, Đoàn Trần Công Danh wrote: []
> Would it work if you always open the file as BINARY?
Yes, I think so.
> And let's all the > conversion done by git via some configs (core.encoding?)?
We already have an attribute, "working-tree-encoding", that can tell Git to do the encoding/reencoding. The advantage of the .gitattributes file is, that it is typically commit into the repo, and travels with `git push` and `git fetch` or `git pull` to the different work stations, so that everybody has the same settings.
In opposite, config files are always local. So that everybody should do the same (local) git config. If that is forgotten for some reason, then different configurations leads often to some kind of chaos.
But I don't have a z/os sytem to test on.