Closed andrecastro0o closed 2 years ago
@StroemPhi The shell script might only work on Unix systems. For Windows the #!
might need to be modified to #!C:/Program Files (x86)/Git/bin/sh.exe
See https://www.gloomycorner.com/git-hooks-on-windows/
https://stackoverflow.com/questions/18277429/executing-git-hooks-on-windows
@andrecastro0o Thank you for looking into this, will try to implement it asap.
probably a dubplicate of #12
@StroemPhi The shell script might only work on Unix systems. For Windows the
#!
might need to be modified to#!C:/Program Files (x86)/Git/bin/sh.exe
See https://www.gloomycorner.com/git-hooks-on-windows/ https://stackoverflow.com/questions/18277429/executing-git-hooks-on-windows
Couldn't get this to run so far. Will try a .bat approch next.
the issue is not the git hook on windows, but how to run bash scripts on windows 8 See perhaps
https://stackoverflow.com/questions/6413377/is-there-a-way-to-run-bash-scripts-on-windows
the issue is not the git hook on windows, but how to run bash scripts on windows 8 See perhaps
https://stackoverflow.com/questions/6413377/is-there-a-way-to-run-bash-scripts-on-windows
thank you for finding, will have a look at it tomorrow
I'm not involved in any way and I know the original issue #12 was closed, but I can't help wondering: is there a reason to want to keep both a Turtle and RDF/XML version of the same data in version control?
@bencomp the idea was to have the ttl for the editors (in a subfolder like src, very soon) and to have the owl at top level for the releases. So I guess the owl does not have to be produced with each single commit, but must be up to date with each release.
@StroemPhi thanks for clarifying. Have you considered keeping one file as the source and using GitHub Actions and Releases to publish derivative files? That could prevent the need of keeping files in sync in version control.
@bencomp hehe, funny that you mention this, as it has just been implemented since v.0.4.2 and we presented this workflow improvement last week at the VIVO conference.
I'm not really sure yet, if this is sufficient though. Looking at all the other OBO ontologies, an OWL is always part of the repo and usually the one in the main branch is used as the source for the PURL to resolve to. As we might want to submit AEON to OBO to get an OBO-PURL, this issue may become relevant for v.1 again. Thus I want to have it open until this is clearer.
chmod +x .git/hooks/pre-commit
.git/hooks/pre-commit
aeon.owl will be created and added to repository. The first time the hook runs it might require an extra commit to include the aeon.owl file