Local repository == the top folder you run the package option in?
Yes the root directory of the locally cloned git repository that would be the main work copy of cerberus.
When I build Cerberus, I open a shell, change directory into cerberus/src and execute the rebuild all scripts from there.
The idea is that you have a full cloned git repository as your work copy. Here you can test out anything git related. Note you should make a backup of the local work repository before doing any merge or rebase in case things go wrong. Git is not entirely infallible
.
You can build all the tools within the local work copy of the git repository. Depending on the tools use to edit any source files, the line endings could be in either crlf or lf. The --package/-p just copies the files as they are from the local work git repository. The final result is a directory name cerbdeploy/build that is created in the users Documents directory where it can be check that the script is copying correctly. The last thing you would want is to copy over is either system specific files or a restricted licence library that you may have missed with .gitignore.
When the --git/-g option is passed it first makes a full clone of the local working repository into Documents/cerbclone fixing any line ending issues outlined in the .gitattribute file and the global git configuration settings. I have
Git for Windows installed and use the fully cross platform
GitKraken, it's
free for non commercial use. If you are do commercial and none commercial, its best to use either the pro version, or go with a git client tool that doesn't place such restrictions, as long as that client installs git for use via the command line.
Special note here: git cannot process non UTF-8 encode files that you tend to find in the Windows world. Special care must be taken with xml files where the UTF in the file's xml header can be different to the actual file encoding (discovered that with the Window Phone target and resource files). It's best to set them as binary, eol=lf or at a push, the actual encoding may work. You should check again that the files are correct before actual deployment. Git was originally a Linux tool and ported over to the other operating systems.
The script then executes the freshly cloned rebuildall script with parameters that were passed, minus the --git option. It then takes over building within the new location. Once the build is done, it copies over the new built files (via the --packag/-p option) and compresses it ready for distribution. You can then check the local work repository and remove any temporary commits before pushing to the remote server.
EDIT:
The deploy package using git requires that it's a valid git repository. It will not work from a pre-built distributed package.
Edit2: One thing that needs a small change is the rebuildall.sh script setting files permissions too early.
Powershell scripts is completely new to me and definitely something I need to learn.
It's still new to me. I wouldn't mind getting my hands on
Powershell Studio to make working with Powershell scripts easier. But it ain't frigging cheap. There is suppose to be a free community version, but I think that you have to create an account to get it.
My preferred tools are:
Those mentioned above (apart from Powershell Studio).
Visual Studio Code. It's cross platform, has a limited git client functionality that comes in handy when you don't want to mess around with your git client of choice. Has a built in terminal and limited script debugging depending on the platform is't being run on. It also supports the changing of line endings.