Symphonious

Living in a state of accord.

Commit Messages as Communication Mechanism

I think Otis Gospodnetić has it spot on:

IMHO, commit messages are an important piece of the communication puzzle, and I feel they are often neglected or completely not even seen that way. Commit messages (that are distributed/delivered to co-developers via email or some other mechanism) help a developer keep others in the loop. They help co-developers stay up to date mostly passively, without having to proactively look for information about recent changes.

This is especially true with distributed teams but I’ve always found it really useful for co-located teams as well. Being co-located you can provide updates verbally but it’s so much more efficient for people to keep track of the commit messages in their own time. It’s like the interruptions of IM vs the when-you’re-ready of email.

A Big Forking Problem

Back when git and GitHub were relatively new to the mainstream, there was a big discussion about how it promoted forking and was potentially bad for community building. Since then GitHub has well and truly proven that it can successfully support significant community and very successful projects. Looking around GitHub though, it’s clear that not every project successfully builds community there and the tendency to fork can still become a problem.

The big difference that I see between projects thriving with GitHub and those where forking looks like more of a problem is that thriving projects have a “campfire” other than the source code for people to gather around. Often that’s a mailing list, other times it’s IRC and various other technologies but there’s always one common place where the community can build. GitHub by itself is unlikely to build up such a community because there isn’t a really good way to engage everyone in conversation. As such, you get a lot of forks and people making improvements, but not really working together and often the various forks never get folded back into the original.

The good news is that despite all the forks often remaining off on their own, it doesn’t seem to be detrimental to the original project. People find the main GitHub repository through other means, mostly links on the web, so there doesn’t seem to be confusion over which fork is the “main” one. On the other hand, most of those forks represent a wasted effort which could have pushed the project forward if only there had been some communication.

Finally, it’s interesting that the GitHub model of anyone creating a fork is far more successful for projects which don’t need a contributor agreement to be signed. In that case, any fork that looks promising can be pulled in without needing extra permissions, so even without the extra communication channel the effort can be utilised. With a contributor agreement, you have to reach out and get the author to sign, which is a significant barrier.

Who’s Committed in my Git Repository?

Note to self: if you ever want to get a simple list of people who have committed to a git repository, the command you want is:

git log --format='%aN <%ae>' | sort -u | uniq

Or for just the e-mail address:

git log --format='%ae' | sort -u | uniq

Or for just the name:

git log --format='%aN' | sort -u | uniq

This is in the help manual but it’s way down the bottom so takes ages to read through to find it.