>>> 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! :-)
