Re: On commit access, patch review, and remaining healthy

[Arun Isaac]

>>> Personally, I think nowadays this purpose is better fulfilled by
>>> good commit messages and git blame. Especially with an editor that makes
>>> it easy to use them to navigate through history (such as Emacs, but
>>> certainly others as well).
>>
>> Because these standards, it is easy to navigate via grep for instance.
>> Git blame is useful once you know exactly what you are looking for.
>> Before that, when I try to figure out the logic behind such change, the
>> commit messages more or less fixed by the standards are very helpful,
>> IMHO.
>
> I agree.  I've come to like GNU ChangeLog commit messages because it
> forces me to lay down the changes I've worked on, and sometimes I can
> spot things that would be better separated in its own commit, or that
> was unintentionally left while testing.

Exactly! I too have grown to like our ChangeLog style commit messages
enough that I use it in my own repositories.

I like to think of them as akin to the Pointing and Calling[1] system
common on Japanese railways. In the Pointing and Calling system, the
railway worker has to not only go through a checklist of items, but also
has to actually *point* (gesturing) and *call" (verbalizing) the
relevant dial or traffic signal. This explicit gesturing and verbalizing
makes them pay more attention and reduces the probability of an
accident. Likewise, our ChangeLog style commit messages force the
committer to explicitly list down the changes and thus catch any lapses
of concentration.

[1]: https://en.wikipedia.org/wiki/Pointing_and_calling

> When reviewing others' work it also give me a clear trail of what they
> did, and I can match the actual changes to their high level
> description.

I agree! :-)