<< Click to Display Table of Contents >> Navigation: IBM i Git Source Commands > LIBSRCEXP - Export Library Source to Git Repo |
Description
This CL command can be used to export and commit one or more source physical files and changed source members from a library to a Git repository.
Use cases
Initial git repository staging - It's good to use this command initially to export all source files and members from a library and commit to a new or existing Git repository. The term "seeding the repository" is a good term to describe the initial export and load of all source member to a git repository.
Automated daily changed source commits - The command is also able to automatically export and commit selected changed source members based on a change date as well. This option is nice if your team is editing source members and it's determined that capturing changes to a Git repository should be a passive process done once a day or periodically throughout the day rather than interactively. Your team could use a mix of SRCTOGIT for capturing changes individually and then use LIBSRCEXP daily to catch any changes that may have been missed by individual user commits.
Command Example to export all source files and members from a library for all dates to seed a new repository or refresh it with all source members that haven't been committed yet
The following example would export and commit all source member changes for all source files in library QGPL for all dates from 1/1/1900 - 1/1/2099. (All source members).
LIBSRCEXP LIBRARY(LIBRARY)
FILE(*ALL)
STARTDATE(*ALL)
ENDDATE(*STARTDATE)
IFSREPODIR(*LIBREPODTAARA)
SRCHEADER(*YES)
SRCDATSEQ(*NO)
REPLACE(*YES)
VALIDREPO(*YES)
IFSMKDIR(*YES)
INITREPO(*YES)
COMMITOPT(*COMMIT)
COMMENT(*DATEUSER)
JOBMSGQFUL(*WRAP)
Command Example to export all source files and members from a library that were changed during for the past 2 days. Yesterday and today.
The following example would export and commit all source changes in library QGPL for yesterday from 12:00am - 11:59pm today.
LIBSRCEXP LIBRARY(LIBRARY)
FILE(*ALL)
STARTDATE(*YESTERDAY)
ENDDATE(*STARTDATE)
IFSREPODIR(*LIBREPODTAARA)
SRCHEADER(*YES)
SRCDATSEQ(*NO)
REPLACE(*YES)
VALIDREPO(*YES)
IFSMKDIR(*YES)
INITREPO(*YES)
COMMITOPT(*COMMIT)
COMMENT(*DATEUSER)
JOBMSGQFUL(*WRAP)
Command Example to export all source files and members from a library that were changed during for the past 7 days. Capture rolling 7 days of source changes.
The following example would export and commit all source changes in library QGPL for yesterday from 12:00am - 11:59pm during the previous 7 days.
LIBSRCEXP LIBRARY(LIBRARY)
FILE(*ALL)
STARTDATE(*LAST7)
ENDDATE(*STARTDATE)
IFSREPODIR(*LIBREPODTAARA)
SRCHEADER(*YES)
SRCDATSEQ(*NO)
REPLACE(*YES)
VALIDREPO(*YES)
IFSMKDIR(*YES)
INITREPO(*YES)
COMMITOPT(*COMMIT)
COMMENT(*DATEUSER)
JOBMSGQFUL(*WRAP)
Parameters
LIBRARY - The library to export source members for. Only source physical files will be listed.
FILE - Source physical file to list. Default - *ALL
Options
Specific source file name
*ALL - include all source files from selected library.
STARTDATE - Start date to query. Default - *TODAY
Options
Specific start date in MMDDYYYY format. Ex: 01011990
*ALL - Start date set to 0101990 and end date auto-set to 01012099.
*TODAY - Use today's date. Gets everything between 12:00am and 11:59pm on current date.
*YESTERDAY - Use yesterday and today's date. Gets everything between 12:00am on the previous date through 11:59pm on current date.
*CURMONTH - Use the current month beginning and ending date. This is NOT a rolling 30 days. It is hard locked to the current month.
*LAST7 - Get the last 7 days plus the current date through 11:59pm. This is a rolling 7 days. Good for scheduling regular automatic commits.
*LAST14 - Get the last 14 days plus the current date through 11:59pm. This is a rolling 14 days. Good for scheduling regular automatic commits.
*LAST30 - Get the last 30 days plus the current date through 11:59pm. This is a rolling 30 days. Good for scheduling regular automatic commits.
ENDDATE - Start date to query. Default - *STARTDATE
Options
Specific end date in MMDDYYYY format. Ex: 01011990
*STARTDATE - Start date setting will determine end date unless a specific date is entered for the end date.
IFSREPODIR - Destination git repository IFS directory. Use this command along with IFSMKDIR-*YES to auto-create any repository directories. Default: *LIBREPODTAARA
Options
Specific IFS path - If you have a specific git repository directory you want to use, enter it. Example repo name: /gitrepos/lib001
*LIBREPODTAARA - If you have created and set the 255 character GITREPODIR data area with a valid repo IFS path you want to use for this library, then the repo set in GITREPODIR will be used as long as it's not blanks.
*LIBFILEPATH - Create a top level git repository based on a prefix of GIT_ combined with the library name. Example repo name: /GIT_QGPL
*CURRENTREPO - If you are setting the CURGITREPO data area in QTEMP via the SETCURREPO command, then you can use this option. Git repo name used will be whatever you set in CURGITREPO as long as it's not blanks.
SRCHEADER - Include source info header at the top of each source member during export. Default: *YES
Options
*NO - Do not write source header info during export. Only use this if you don't plan to import source members again or don't need to maintain source type and text in standard source files.
*YES - Write source header info during export. This option should normally be set to *YES because the header info is needed during import of source members to maintain the appropriate source type and text when a member is imported.
SRCDATSEQ - Include source dates and sequence numbers during source export to IFS. Default: *NO
Options
*NO - Do not include source dates and sequences. Use this option if you are comfortable not having source date and sequence info in your source member. Most modern developers rely on source code diffs rather than dates info and line numbers to compare source member for changes. Your team needs to be emotionally ready for eliminating source dates and sequences
Note: Eliminating source dates and line sequences will be a cultural decision for your development team to make. Generally we recommend the *NO option for NOT maintaining source lines and dates, which allows IFS source members to be edited from the IFS or a PC with any source editor including notepad, notepad++, vscode and more.
*YES - Write source dates and sequences for each line. This option should normally be set to *YES only if you are using RDI and want to maintain line dates and sequences or you are using SEU and want to maintain line dates and sequences.
Note: If your shop is not culturally ready to make the change and get rid of source dates and line numbers, this option can be used when exporting source members.
REPLACE - Replace existing IFS member if one has been exported previously. Default: *YES.
Options
*NO - Do not replace existing IFS source member.
*YES - Replace existing IFS source member.
VALIDREPO - Check if IFS directory is a valid git repository. Default: *YES
*NO - Do not check if IFS directory is already a valid repository before exporting. Use this if simply exporting to the IFS and there is no git repository required.
*YES - Check if IFS directory is already a valid repository before exporting. Use this if the IFS directory needs to be a valid git repository for version control.
IFSMKDIR - Create IFS directory and git repository. Default: *YES
*NO - Do not create IFS repository directory paths automatically.
*YES - Create IFS repository directory paths automatically.
INITREPO - Init git repo after directory create. Default: *YES
*NO - Do not create Git repo after directory path creation.
*YES - Create Git repository right after directory path creation.
**Note: If IFS directory already exists, we DO NOT attempt to initialize the Git repo because one may already exist. A manual review and Git init will be needed to initialize the repository in this case if needed. You can either create your Git repository before running SRCTOGIT or you can let your first call to the SRCTOGIT command create the directories and repository automatically.
COMMITOPT - Commit changes after source member export to IFS. Default: *COMMIT
Options
*COMMIT - Export source member to local git repository directory and commit to local repository in IFS. Use this if you are leaving git changes in the IFS or plan to push them to a remote repository later. This is the default option.
*COMMITSYNC - Export source member to local git repository directory and commit to local repository in IFS. Then pull and merge any remote changes and push them back to the repository. Use this option normally for a full git edit and version life-cycle where the local copies stay in sync with the remote repository at all times.
*COMMITPUSH - Export source member to local git repository directory and commit to local repository in IFS. Then push changes to remote repository. This option only pushes changes, but does not pull and merge remote changes with the local repository.
*GITADD - Export source member to local git repository directory and add/stage to the commit list in local IFS repository. Use this if you want to stage a file for a future commit that will happen later. Good for staging multiple files for a single commit later by the GITCMD CL command with a commit option. Example commit: GITCMD CMDOPTS('-commit -m "My Commit of Many Staged Files')
*NOCOMMIT - Use this option if just simply exporting source member with no intent to commit to git immediately.
COMMENT - Commit comment. Default: *DATEUSER
Enter a commit comment or special value.
*DATEUSER - Write date info and user ID into commit comment automatically.
AUTHORITY - Authority for new file. Default: *INDIR
Options:
*DFT - Owner of file granted *RWX, *PUBLIC will have *NONE.
*INDIR - Use the IFS directory authority to determine permissions.
*FILE - Use the original source file for the FROMMBR to determine authority.
*INDIRFILE - Use the IFS directory authority and then use authority form the FROMMBR.
Note: It may be a good idea to set the IFS directory permissions accordingly and set the AUTHORITY value to *INDIR to make sure the directory permissions are set adequately so there are not any odd member permission issues for any developers access files in this directory. *ALLOBJ authority will bypass any permission issues of course but not usually recommended.
JOBMSGQFUL - Job message queue full action. This option should be used to make sure your job does not end abnormally when the job message queue fills up. This can happen when processing a lot of source members so it's a good idea to set it to wrap. Default: *WRAP
Options:
*SAME - Do not change.
*WRAP - Wrap job message queue if it fills up. Your user must have authority to do a CHGJOB command.
*SYSVAL - The value specified for the QJOBMSGQFL system value is used.
*NOWRAP - The message queue does not wrap when it is full. This action ends the job.
*WRAP - The message queue wraps to the start of the message when full and starts filling the message queue again.
*PRTWRAP - The message queue wraps the job message queue when full and prints the messages that are being overlaid because of wrapping.