() Stefano Lattarini <[email protected]> () Thu, 24 May 2012 13:37:33 +0200
> I don't agree that it's required There's a misunderstanding here. I'm not saying that the rationale should be *mandated*, as in some cases it is truly overkill [...] What I'm saying is that, *when* a rationale about the why and how of a changeset is to be given, the proper place for it is the commit message; so, *when* it's needed, it *must* go in the commit message. I understand completely now what you're saying, but still i disagree, in defense of maintainer prerogative. Consider some project w/ a "TODO file" which lists planned changes, and archives completed changes, along with detailed design / implementation (and re-design / re-impl :-D) notes, say. That file is as good a place as any for rationale information. Of course, it would be good practice to (distribute and) refer to it, just like it is good practice to refer to bug reports, from the ChangeLog. > the "and why" is not universally highly valued). Which is real a shame. I think that depends on the project and its maintainer(s). Certainly, many times ttn the historian wishes ttn the coding cowby had been more rigorously forward-thinking in ChangeLog maintenance, but not always. IME, those wishes are flanked by annoyance and regret but never shame.
