Creating a global .gitignore file

It's possible to create a global .gitignore file¹ that is automatically shared among all your repositories.

Why should I do this in the first place? Well, there are a couple of reasons.

One example is of course, I want the same rules to apply to all my repositories.

But, in my case, at work, we are actually using Subversion and not Git. But I do use Git.

And I do not want to pollute the entire Subversion repository with my .gitignore files.

So for me, this is a valid solution.

Let's check that I do not already have this configuration setting active:

git config --list
user.name=Mr. Bear
user.email=mrbear@bears.com
svn.rmdir=true
alias.co=checkout
core.excludesfile=/home/mrbear/.gitignore_global
core.autocrlf=input
core.ignorecase=false

You'll notice that among my properties, I already have a core.excludesfile=/home/mrbear/.gitignore_global.

I added it as follows:

$ git config --global core.excludesfile ~/.gitignore_global

Than just populate it like you do with any .gitignore file.

References

[1] Docs github.com - Configuring ignored files for all repositories on your computer

https://docs.github.com/en/github/using-git/ignoring-files#create-a-global-gitignore

Maven and the Dangers of Snapshots

Recently we've been causing problems in the regular builds of branches of our software.

Basically the problem is our own fault and is related to Maven Snapshots.

According to the guide¹, a Snapshot is a library that is still under development, and may change rapidly as new versions of the Snapshot are pushed to the Nexus regularly.

If a dependency on a Snapshot is defined in your pom.xml, then Maven, as it should, always picks the latest Snapshot.

This is fine and dandy if you are currently developing your software, and you want the newest of the new of the libraries that your other software teams are developing.

The Problem

It means that once you create a stable release of your software (and the appropriate Git branch for it to live in as well, of course) it is important to replace the Snapshot in the pom.xml with the appropriate released version.

We neglected to do just that.

The Consequence

Our branch containing the release version of our software suddenly bombed with compile errors in the Deployment Pipeline.

This caused the maintenance people a headache, as the Git revision of the branch had not changed, between the previous build (which compiled just fine) and the new build (which bombed).

Despite the build being pulled from Git with the exact same revision, it was technically different from the previous build.

All because we kept developing the Snapshot and pushing it into the Nexus.

What we should have done

• create a proper release of the library
• change the pom.xml in the branch to refer to this release.
• create a new snapshot of the library
• use the new snapshot in the pom.xml of the master branch (which is used for development)

Now the build of both the branch as well as the master should compile again.

References

[1] Apache Maven - Getting Started

https://maven.apache.org/guides/getting-started/

Continuous Releasing of Maven Artifacts

https://dzone.com/articles/continuous-releasing-maven

Update: reference added.

Git and Subversion at Work

At my work we are still using Subversion, and some of my colleagues have started using Git locally, coupled to the remote subversion repository.

I am intrigued in how to get this working on my workstation and this contains some of my thoughts on it.

Advantages

• since we moved to a virtual svn server, it is becoming impossible to do something worthwhile like request the svn history of a file or use "Annotate" in IntelliJ and receive a result within a reasonable time period. It currently takes 15 minutes or longer. A local git repository alleviates this problem immensely.
• the creation of branches can be done locally, which is a big help if I need to work on multiple issues at the same time, and I need to switch repeatedly.
• a local git repository helps me to perform multiple checkins related to the same problem, without inconveniencing any of my colleagues. I can even decide to merge my different checkins together and submit them to subversion as one big changeset.
• the merging is said to be painless and conflicts are very very few, even with rather complex checkins. One of my experiences with Subversion in combination with IntelliJ, is that IntelliJ sometimes is unable to merge it properly and changed code (or duplicated code) is just added to the top of the code file.

Disadvantages

• retrieving the entire svn repository using git (which is the default) is taking a long time (several days). I let it run, but I decided to switch to selecting only a few branches that interest me.
• I still am trying to get to grips with the fact that just checking in isn't enough. After I check stuff into my local repository, I still need to merge it to the master branch and then submit it to subversion.
• it was confusing for a moment, when I noticed that my changes in one branch were automatically visible when I switched to another branch. But this is perfectly normal and happens when you have changes that are yet uncommitted.
• it takes a bit of effort to keep everything straight in my head. Especially in which branch I am currrently working.

JIRA, Git and IntelliJ

I do like the seamless integration between JIRA, IntelliJ and Git. I can just stay in IntelliJ, and search for specific task in JIRA. IntelliJ will automatically create a Git branch with the appropriate JIRA task number as well as a new Change Set.

It is even possible to automatically move the JIRA task to "In Progress", though for now I do not make use of this functionality as I would like to have a little bit more control.

Conclusion

I like git a lot. In the past I was able to submit my changes into Subversion at the touch of a button. The setup now of a local git and a master branch and a subversion remote repository does require several extra steps to check anything in.

But those added steps are worth the effort, compared to all the extra capabilities I gain.

References

[1] git website - git-svn Bidirectional operation between a Subversion repository and Git

https://git-scm.com/docs/git-svn