Marcus Folkesson

Increase the quality of your commits with pre-commit pre-commit [1] is a framework for managing and maintaining pre-commit hooks for git. By running hooks before any commit, many small pitfalls could be avoided before being pushed and will spare reviewers time and energy. Such hooks could for example check that commit messages follow a specific format or that the code pass a lint test for a specific type of file.

Git version in CMake All applications have versions. The version should somehow be exposed in the application to make it possible to determine which application we are actually running. I've seen a plenty of variants on how this is achieved, some are good and some are really bad. Since it's such a common thing, I thought I'd show how I usually do it. I use to let CMake determine the version based on git describe and tags, the benefit's that it is part of the build process (i.

Patch changelogs with git-notes Git notes [1] is a neat function that has been around since v1.6.6. Notes is a kind of metadata that belongs to a certain commit but is stored separately (different git object) from the commit itself. The fact that it's a separate git object is important, it will therefor keep the commit hash intact, and as a bonus - it has its own diff log.

get_maintainers and git send-email Many with me prefer email as communication channel, especially for patches. Github, Gerrit and all other "nice" and "user friendly" tools that tries to "help" you to manage your submissions does not simply fit my workflow. As you may already know, all patches to the Linux kernel is by email. scripts/get_maintainer.pl (see [1] for more info about the process) is a handy tool that takes a patch as input and gives back a bunch of emails addresses.