Ever find yourself moving a git tag to a new commit? You’ll probably know this procedure consists out of three steps;

• Removing the existing tag from your origin
• Manually moving the tag (using -f to allow moving)
• Pushing the tag back your origin

Since this procedure is more cumbersome that it could be, behold, a quick and easy life hack to automate this process into a single custom command.

I was reviewing some pull requests at work today. One of the PR’s had an updated composer.lock file. We usually check if the reference matches the version for this update, to see if that commit is actually released on the module’s master branch:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

"name": "company/module_name",
- "version": "0.11.0",
+ "version": "0.12.0",
"source": {
	"type": "git",
	"url": "ssh://git@stash.company.net/packages/module_name.git",
-	"reference": "19ecfcb286052457697caad3359d7817e2dfa2f5"
+	"reference": "2c539864d72baede7f169f15eec8c3317e26c1bc"
 },
- "time": "2014-10-08 11:12:23"
+ "time": "2014-11-18 16:47:02"

Usually, this reference matches the hash of the commit we’ve tagged as this version. In this particular case however, the hash mentioned in reference was nowhere to be found in the commit log. So what’s going on here?

The quick, easy and complete way:

Well. Here we are!

New year, new approach to blogging.

In the past year I haven’t managed to push out a lot of blog articles though I’ve been working with loads of new, interesting technologies and approaches.

Being a programmer, I blame the software I use to blog. In my case that’s the TYPO3 installation at rem.co. It’s recently been updated to TYPO3 6.0, and I haven’t gotten around to fixing all the bugs that appeared after such a major upgrade.

Moreover, that site uses the ancient tt_news plugin as a blog substitute, which makes blogging a bit… troublesome to put it mildly. Especially “advanced” stuff like including code snippets and multiple layouts in one article.