We recently added Git support to PrimalScript and, subsequently, to PowerShell Studio. You can read about it here.
As promised in the previous post, I will tell you a little bit more about how this works, how you can customize it, and what we have planned for it in the future.
The MS SCC API (Microsoft Source Code Control API) has become old and not very broadly supported, and even Microsoft does not seem to be interested in updating or expanding the interface. However, virtually all source code control systems support a command line interface, so we here at SAPIEN decided to use only command line tools for our new source control interface—Universal Version Control System.
PrimalScript detects a source code control system through the presence of a configuration file. I will use Git as the example throughout this article, but this information easily applies to any command line driven system. The same mechanisms that apply to PrimalScript also apply to PowerShell Studio.
Take a peek at the following folder after you have installed the latest version of PrimalScript or PowerShell Studio: C:\ProgramData\SAPIEN\Version Control Providers
The file ‘Git.inf’ is what tells PrimalScript that there is a Source Control Provider named ‘Git’.
Let’s examine the ‘Git.inf’ file to see how things work.
The ‘Detect’ section is what tells PrimalScript about the system. The presence of a ‘Folder’ named ‘.git’ indicates that the commands herein apply to any file in a folder containing such a subfolder. ‘System’ indicates the path to a file that can be used to detect if the system is installed. If you installed Git in a different location than the default, you will need to edit the path. ‘Name’ is the display name.
The ‘Commands’ section lists all available commands for this particular Source Control System. For each command listed here, there must be a corresponding section in the file containing its data. We will use the ‘Add’ command as an example.
Before we get to that, let’s take a brief look at the icons used in the user interface. The folder containing ‘Git.inf’ also contains a ‘Git Images’ folder. Its name is derived from the system, so ‘Git.inf’ implies there is a ‘Git Images’ folder.
The name of each command listed corresponds to a png file in the ‘Git Images’ folder. These are the images used in PrimalScript’s user interface.
If you do not like a particular icon we chose, you can easily substitute your own.
Now back to the commands.
As the name implies, the ‘Add’ command adds a file to the repository for that current folder. We have received some feedback that users would like to enter their own initial command rather than us just hard-wiring ‘Initial commit’, so I will show you how to do that.
Each command can have any number of command line instructions which are executed in order, and PrimalScript will wait for each command to complete before executing the next one.
For the ’Add’ command we have two command line instructions:
git add %FILE%
git commit -m “Initial commit” %FILE%
Anything in this file bracketed by % characters is considered a macro. The only macro resolved by PrimalScript at this time is %FILE%. It will resolve into the full path of the currently active editor file. Any other macro will be resolved by prompting the user.
Let’s take a look at the ‘Commit’ command, which already prompts the user for a comment.
You see a macro %MESSAGE% here. PrimalScript has no idea what that is, so it looks for a value in the inf file “MESSAGE=” and uses the corresponding text to prompt for a value.
You can apply that same mechanism to the ‘Add’ command.
Save ‘Git.inf’ and restart PrimalScript. The inf file is loaded on startup, so any changes made to it will require an application restart.
After saving the inf file and restarting PrimalScript, when you add a file to Git you will be prompted for an initial comment.
There is currently one caveat—please make sure to make a backup of any modifications you make to the inf file. Since this is under development and subject to change without notice, any time you install an update the inf file will be overwritten and replaced with the standard version.
In the future, we will provide a mechanism for ‘User’ versus ‘System’ files. For now, you should assume that any changes made will be erased by an update and will need to be reapplied.
We have quite a number of features and improvements planned. We love to hear from you, so feel free to provide additional feedback or suggestions in the feedback section of our forum.