Using AI As A git Helper
After spending some time with ChatGPT over the past month, I decided it was time to learn some other AI tools. ChatGPT works well for some coding tasks, but ends up wasting time in so many others. The more complex the technical inquiry the more off track ChatGPT would get. Time to explore some code and DevOps specific AI assistants. One of the first uses was AI as a git helper. Here is how it faired.
Next up on my list is JetBrains AI assistant. I use the JetBrains tool kit extensively in my work and this tool integrates directly into my IDE for PHP apps like WordPress, Web Apps (JavaScript, TypeScript), the Java-centric IDE, and all the other primary task-centric IDE’s JetBrains provides.
JetBrains AI Assistant Overview
The JetBrains AI Assistant is a service provided by JetBrains for use directly in the IDEs. It is a paid service that is currently charging $100/year for a subscription. There is a free week-long trial to see if it can help.
One of the things I like about it is that it provides multiple context-driven AI interfaces in the IDE. Highlight a chunk of code and ask it to find potential problems; A second later a side window opens reviewing the code along with potential issues and suggestions for improvement. Even in the basic form it provided some great suggestions for avoiding errors in bash like “user does not have privileges” with a catch to exit gracefully.
AI Helping With git Commits
One of the features I found fairly quickliy was using AI as a helper for git commit messages. I prefer stacks of smaller commits when working on projects over one big commit; Something I learned when working on larger teams and having to resolve conflicts — cherry picking or conflict resolution is MUCH easier with small commits and the conflicts themselves seem to occur far less frequently. The problem with doing 12 small commits over a few hours versus on huge “fix all the bugs” commit means a lot of commit messages.
Inevitably, whether doing a large commit or several small commits — the messages become rather useless fairly quickly. “Fixed all the bugs” doesn’t tell the rest of the dev team a damn thing about what was really changed. If they want to see what was done they are now checking your commit diffs and figuring it out. Not super efficient.
AI as a git commit helper to the rescue. One of the cool features in. JetBrains AI is that the commit manager in the IDE has a little assistant icon that will review what is about to be committed and write a decent details message about it. This has already saved me a lot of time in the 20+ commits I push daily. Yes, sometimes it is clueless and writes an inaccurate message — but most of the time it writes an accurate message with more details than I’d have added myself.
Using AI As A git Submodule Helper
Commits are one thing, but time to git in a deeper into this AI stuff. In between having it review code in both bash and PHP, I had mixed results. If was often “in the neighborhood” or providing a good solution, but often missed a few steps, or key parameters. I’ll write more on that later. For now, let’s focus on the git helper focus of this article.
One of the big pieces of my current DevOps solution is using AWS ECS and “kits” that help not only bring together the code elements but to also define the IT stack for both local development and cloud deployment. While that is going well, it turns out the easiest way to build the stacks over on the AWS container service is to use a “DevOps Kit” repository that brings in critical subelements, the codebase for my SaaS application for example, as submodules.
The problem with submodules is that git is notoriously finicky about how they are implemented. If often gets confused, or confuses users, on what gets brought in where. Which submodules go to which directories, what branch they are on, and even when and how they are updated. With a build kit like these you want to have full control to ensure the right pieces on the right branches end up in the proper locations.
For my stack, I want to be able to checkout a “develop” , “staging”, or “production” branch on the main kit repository. When I push an update to those specific branches — well staging and production at least — I want the CI/CD pipeline for the cloud environment to automatically build and deploy the full cloud stack to the staging or production system.
Doing this properly means that the git repository needs to ensure the submodule branches track the main kit branch. If I am checked out on staging on the main kit, I want to ensure all the underlying components are also pulling from the staging branch. The standard operating procedure for the dev team mandates that things committed to those key tracking branches are ready for use by the entire develop team, ready for release testing on the staging servers, or is fully tested and ready to deploy to production.
Thankfully the AI assistant for JetBrains was able to assist. I could open a sidebar chat window , highlight a bash script that the Code Builder script runs before each container build, and ask it to help ensure the submodules track the parent branch, are pulled as needed, and the resulting update is committed back to the parent branch. It quickly updated my script to provide a super simple two-line addition, the thing to defined the branch variable and the foreach git command.
#!/bin/bash
. ./tools/myslp_submodule_defs.sh
BRANCH=$(git rev-parse --abbrev-ref HEAD)
echo "Updating submodules..."
git submodule foreach "git checkout $BRANCH; git pull --rebase"
git submodule status
git commit -am "Commiting updated submodules"
git push
For this use case it worked perfectly.
AI Fixing A .gitmodules Misunderstanding
After I realized that my tools were not working as intended, I also asked the AI to clarify a misunderstanding I had about how the branch = . setting in the .gitmodules file operated. From various articles referencing this lesser-known “special operator” feature it turns out that setting does NOT in fact force the submodules to checkout the parent module branch of the same name. Instead it forces it to stay on its checked out branch regardless of project settings.
Here is what it had to say:
Image by ChatGPT 4 via DALL-E
AI Assisting With Improved Git Submodule Processing
In this case I wanted to stop running an extra git checkout command if the submodule was already on the current branch. While git provided a great submodule foreach loop script to test for it I did not provide the complete context and as such if left out an all-important quoting mechanism in the script. Here is the version it created for me after I asked it how to fix the highlighted command:
BRANCH=$(git symbolic-ref --short HEAD 2> /dev/null)
if [ -z "$BRANCH" ]
then
echo "Error: BRANCH is not set or currently in a detached HEAD state on main MySLP Kit" >&2
exit 1
fi
echo "Updating submodules on branch $BRANCH..."
git submodule foreach 'SUBMODULE_BRANCH=$(git symbolic-ref --short HEAD); if [ "$SUBMODULE_BRANCH" != "'$BRANCH'" ]; then git checkout "'$BRANCH'"; fi; git pull --rebase'
git submodule status
git commit -am "Committing updated submodules"
git push
In the original foreach loop I had a test that looked like this:
git submodule foreach "SUBMODULE_BRANCH=$(git symbolic-ref --short HEAD); if [ "$SUBMODULE_BRANCH" != "$BRANCH" ]; then git checkout $BRANCH; fi; git pull --rebase"
AI Assistant quickly determined that since my entire foreach command originally began with “, it was not properly expanding $BRANCH as it comes from outside the foreach command loop. The complete code-sample before this shows the modified version where using single quotes (‘) to define the start/stop points on the string, mixed with the variable name in between allows for a run-time concatenation that fixes the problem.
Another win for AI where a direct relevant answer was a click away, saving some search engine entries and walking through a few less-direct web pages of answers.