Happy New Year and Remember to Update your Copyright Date!

I’m still living in 2023, even though it is now January 1, 2024. But my git repositories don’t need to live in 2023.

Picture this: you have a line at the top of your source file that looks like this:

// Copyright (C) 2012-2023 Joelle Maslak, All Rights Reserved

The problem is that I’m not usually working on the comment in the file, I’m usually working on something else in the file and forget to update these lines when I edit the files. I found a simple git hook to check for outdated copyrights on new checkins.

This plugin was missing an essential feature, however: I do sometimes check in stuff that has an older copyright, and I need to preserve that copyright. So I made a small modification to the script to let me override the copyright, and I’ve made it available via my fork (I’ve also submitted a PR for the upstream, so it may be updated by the time you read this).

Once I put the pre-commit-copyright-check in my personal ~/bin directory on my computers (via my dotfiles repo installer), I needed to add this hook to all my git repos. Git supports “hooks”, which are essentially code that gets executed when certain actions are taken. The interesting action in this case is the pre-commit hook, which must return a true value (0) before git will allow you to commit code.

To do that, I modified my .bashrc (if you use ZSH or another shell, you will need to add this to the appropriate shell startup file) to have this code:

# Make sure git copyright hook is in place
for i in "$HOME"/git/*/*/.git/hooks ; do
    if [ ! -e "$i/pre-commit" ] ; then
        ln -s "$HOME/bin/pre-commit-copyright-check" "$i/pre-commit"
    fi
done

In my environments, all my git repos live under either ~/git/antelope (my personal stuff) or ~/git/<organization> (stuff I’m doing as part of an organization). It loops through all my repos, checks for an existing pre-commit hook, and, if one does not exist, creates a new link to this hook in my ~/bin directory. I do this in my .bashrc so that it is executed on subshells, not just login shells, as that makes it more likely the hook will be in place when I’m working on new (to me) repositories.

When this is done, if I try checking in a file with a copyright line but an old year, it will give me an error:

[0] jmaslak-dt:demo$ git commit -a
bad-copyright.pl has an outdated copyright date
Commit aborted

Thus, it doesn’t even let me commit the code until I fix that. I can of course override it:

[0] jmaslak-dt:demo$ NO_COPYRIGHT_CHECK=1 git commit -a -m "Ignore Error"
bad-copyright.pl has an outdated copyright date
Bypassing copyright check due to NO_COPYRIGHT_CHECK env variable
[main (root-commit) cff6865] Ignore Error
 1 file changed, 14 insertions(+)
 create mode 100644 bad-copyright.pl

This isn’t Perfect

This isn’t a perfect hook, but it’s good enough. There are some limitations with the hook:

1. It’s not very smart about what it considers a copyright and what it doesn’t.
2. The override mechanism is clunky
3. It’s a git hook

For the first and second issue, I will probably eventually rewrite this check to be a little more user friendly. But for the third aspect, the limitations of git hooks, there are more difficulties.

Only one hook of any given type can exist at any time, so I won’t install this check in repos that already have a check. I could certainly modify the existing pre-commit checks in those repos and add this code, but today I don’t do that, namely because I don’t generally use git hooks otherwise.

Secondly, git hooks are not part of your checked-in code. They are not version controlled, and they are not shared by other users. They are not enforced on the server side, but only on the client side. For me, this is fine: I don’t want to enforce this stricture on a team, I want to enforce it only on me. But if I did want to enforce it on a team, it would be better to tie this logic into my continuous integration infrastructure, the project’s test infrastructure, or use a Github action (if I’m using Github).

Not Just Copyrights

A reader that is observant could probably find other uses for similar checks. For instance, if a team member got married and changed their name, they might use a script like this to remind them to update their name, by looking for instances of their old name. Likewise, companies and divisions within companies tend to change names frequently, and this can be used to ensure old names do not continue to be used.