Today I remembered that in my previous work at smartb we used to do a lot of pair programming. Surprisingly, something that really helped in the acceptance of pair programming was a tool called git-duet. Git-duet makes sure that when two people work on a project, they both get attributed on GitHub. Just this small change of people getting the attribution on GitHub improved the motivation to pair program quite a lot.
When I last used this tool, it used quite a hack to make sure that both developers would show up in GitHub: In git, a commit can actually reference two people: An author (as in the person that wrote the patch) and a committer (the person that integrated the code into the repository). In most projects, this is going to be the same person but there are some projects where this is different. The Linux kernel still has a system where people send in patches by e-mail. Those patches are created by a contributor (the author) but integrated into the kernel source code by one of the maintainers (the committer).
Git-Duet was (ab)using this feature to set one of the people who were pairing as the author and the other one as the committer. This led to GitHub showing both profiles and counting the contribution in both developers’ contribution graph.
When I checked the source for git-duet again in preparation for this blog post, I learned that the maintainers added an alternative way of setting the pair recently.
As I learned, git has a feature called trailers. The man page describes them as follows: lines, that look similar to RFC 822 e-mail headers, at the end of the otherwise free-form part of a commit message.
This commit from the git-duet repository can serve us as an example for how a commit with trailers can look:
commit 51344446aecba6a11c28859d076f0effd3187515 Author: Tom Kiemes <firstname.lastname@example.org> Date: Fri Mar 15 15:02:56 2019 +0100 Reset original global git config after tests If a contributor running the bats tests locally had a global git config for `init.templateDir` or `core.hooksPath`, the values would be cleared by the tests. Co-authored-by: David Ansari <email@example.com>
git interpret-trailers command, we can extract the trailers from this commit
--format=%B logs just the commit message without any indent) :
$ git log --format=%B -n 1 51344446aecba6a11c28859d076f0effd3187515 | git interpret-trailers --parse Co-authored-by: David Ansari <firstname.lastname@example.org>
Since these messages are now easily machine readable, third party tools can use them.
Github for example parses the messages that use
and displays the authors together like this:
Gitlab also added support for parsing trailers and linking the names to user profiles a while ago.
Apart from being a source of data for code hosting platforms, trailers can also be useful in other ways. Commit messages won’t get lost so you can use the commit message instead of a ticket in some task management system that might be replaced later. I think it is also nice to attribute people who were involved in tasks separate form development to show that a change is always a community effort. This commit to the Linux kernel for example contains three additional types of trailers:
syzkaller found a way to trigger double frees from ip_mc_drop_socket() It turns out that leave a copy of parent mc_list at accept() time, which is very bad. Very similar to commit 8b485ce ("tcp: do not inherit fastopen_req from parent") Initial report from Pray3r, completed by Andrey one. Thanks a lot to them ! Signed-off-by: Eric Dumazet <email@example.com> Reported-by: Pray3r <firstname.lastname@example.org> Reported-by: Andrey Konovalov <email@example.com> Tested-by: Andrey Konovalov <firstname.lastname@example.org> Signed-off-by: David S. Miller <email@example.com>
A list of even more common trailers can be found on the git wiki.
intrepret-trailers command also allows you to add trailers to commit messages. This can become really useful
as plumbing for higher-level tools (like git-duet for example). It is probably best to refer to the man page for many additional examples:
So to sum it up: The next time you are pairing, add a
Co-authored-by: trailer to the end of the commit message. This way, tools
can automatically credit all of the people that worked on a commit but more importantly future developers will also know who to talk
to if they ever have questions about a specific commit. Happy pair programming!