version control

sr.ht (“sir hat”) – open source software suite for managing your software development projects

sr.ht – pronounced “sir hat” – is a new competitor in the world of GitHub, BitBucket, and GitLab. Much like all of these, you can either self-hosted it or use a managed service. It might not yet be as fancy, polished, and cool (I think they need a better name and the domain) as its competitors, but there are a couple of reasons that might make a difference when making a choice:

Open Source. From a quick look, sr.ht is distributed under the GNU Afero GPL.
Modular. The suite consists of the following components:
1. git – git repository hosting service
2. build – continuous integration service
3. lists – mailing lists service
4. todo – ticketing system / bug tracker
5. dispatch – task dispatcher and integration service
6. man – markdown and git-based wiki service
7. meta – account management service

Learn Git Branching

“Learn Git Branching” is a very cool, interactive tutorial for branching in git version control. It starts off with the very basic concepts, even covering simple commits, and continues step-by-step all the way to merging, cherry-picking, rebasing, and working with remotes.

Super cool!

Go Monorepo

As a maintainer and contributor to multiple, and often related, git repositories, I often find myself thinking that there must be a simpler way.

Consider, for example, a variety of CakePHP plugins that we develop and maintain at work. Sure, each one provides a completely separate bit of functionality and has its purpose as a standalone project. But, at the same time, they all have enough overlap that we use a common cakephp-plugin-template repository to keep things in sync, and also require cakephp-utils plugin from all of them.

It’s only natural to consider other ways of doing things. Sure, I tried git submodules before, but they don’t quite cut it. Something is still missing.

Today I came across the Go Monorepo website. Which makes me wonder even further down this road. There are also a few other tools and alternatives mentioned in this article.

That’s not something that I’ll jump into right now, but it’s definitely something I’ll consider to try out in the nearest future.

Highlights from Git 2.19 and PHP syntax

GitHub blog covers the highlights from Git 2.19, which was recently released.

One particular change that I want to highlight (which GitHub skipped in their highlights, but which exists in the Git release notes for this version) is the syntax pattern update for the PHP files.

Let’s have a look at the full diff of this release. The particular change I am referring to is in the userdiff.c file. Git now understands final, abstract, interface, and trait keywords.

If you are not sure where and how it is used, here are a couple of useful links for you:

.gitattributes documentation section on settings the syntax of the file for diffs. Basically, you just need to add “*.php diff=php” to the .gitattributes file. Unfortunately, this is done on a per-project level, rather than globally on a user level. (See this blog post for more details).
More info on the same subject: How Does Git Know What Functions Look Like?

Now that you have it all configured, there are a couple of ways to benefit from this functionality. First, you’ll see a more useful context comment in the diffs. Here’s the screenshot (using an older git version still). On the left, the diff without the PHP syntax configured, and on the right is the diff with the PHP syntax configured:

As you can see, on the left, the context shows that the change was done somewhere in the ChangeLogTrait trait. On the right, the context is much more specific – it shows that the change was done in the public function changelog.

This makes reviewing code changes a lot easier. But there is also one other place where this is useful – in reviewing the history of a particular function. For example, running “git log -L :changelog:ChangelogTrait.php” will produce the git log output containing only the commits and diffs on the function changelog in the file ChangelogTrait.php. Very handy!

Semantic Versioning : Version 0 is unstable

We’ve been using Semantic Versioning for quite a while at work now. It’s easy to explain and follow, and it provides valuable context to the numerous releases of the projects and components that we are doing on a daily basis.

Turns out, however, that I missed a small, but important part of the standard. All releases in major version 0 are considered to be unstable, so even if they introduce backward compatibility breaking changes, there is no need to increment the major version to 1. Here’s the relevant quote:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you are relying on the semantic versioning in your projects, make sure to check your dependency management tool, to verify that it handles major version 0 correctly. Gladly, for us, composer does the job:

The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.