Giving Credit Where Credit is Due

One of the best things you can do for your project is highlight the contributors who are helping make it a success. Every patch counts, and every now and then you get someone in the queue who blows you away with a first patch that traces down some sneaky, hidden bug that you know took hours to track down. Attributing such patches has always been a matter of dropping the contributor's name into a commit message and thanking them in the issue in the past, but thanks to Git on there is now a better way.

This may be old news for most folks, but I didn't discover this feature until just a couple months ago. It turns out that user profiles on now include a Git attribution heading under which you can find the appropriate command line option to pass to git commit to attribute that user with a patch.

Attributing svendecabooter

By way of example, I recently committed a patch submitted by svendecabooter. I still formed my commit message using the tried and true format (including both the issue number and his username), but I also added the indicated text to the command:

git commit --author="svendecabooter <>" -m "Issue #1197512 by svendecabooter: pass the entity rendering language down to the linked fields when rendering product fields."

Thanks to Git, even though I am the one committing the code, he is the one credited with authorship of it. This is visible both in the log for that commit and on the committers page for Drupal Commerce. Many thanks to the team for working this all out and helping maintainers give credit where credit is due.



Seems I made it to the example \o/ Smile
I've been starting to use this as well recently, when I stumbled upon the info in user profiles.

I think it's a really good improvement to get more people actively involved in the issue queue, so we can only applaud that. Thanks Git team for exposing this!

I tend to encourage patch contributors to commit the change locally writing the commit message themselves, and then export it using git format-patch. After that I will just have to apply it using git am to have them credited in the project history, if the commit message is not perfect I first try to make the author fix it (education is slow but rewarding in the long term), and only if strictly necessary I operate on the commit using git commit --amend.

I think this is the “git way” to contribute single patches, I see git diff and git apply as tool meant to develop a change more than committing it permanently to the project.

I also tend to discourage the use of git commit -m "Commit message", the -m makes you prefer only a short commit message which in general should be avoided. The general form of commit messages IMHO should be:

Short commit message, a brief description of the WHAT

Long commit message after a blank line, a better description of the WHAT and
WHY the change is necessary and HOW it is implemented, maybe with the full
error messages it fixes and maybe with some performance comparison of before
and after if appropriate.

and this is best done letting git fire up the editor to compose the commit message interactively. For trivial changes using only the short form is OK of course.


It's funny that we talked about this a couple days ago, and when I googled for more info I find your post.

Anyway, I'm trying to do this correctly from here on out. But my first attempt has yet to "take" on I'm hoping it just takes a while for to update the committers page.

Thanks Ryan. I've been doing this incorrectly for the last few commits, so I intend to do it this way from here on out.

By the way, I recently learned about a Greasemonkey script called Dreditor which streamlines patch review. Specifically, it adds a button called "Create commit message" which automatically creates the git commit message for you, including the authoring info, so you can just paste it into your command line and go. Pretty slick!

I've seen those dreditor created comments before but hadn't tried out the script yet. I really should with as much review as I do. Tongue