Richard Levitte <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> on Tue, 11 Sep 2007 12:22:43 +0200, "Julio M. > Merino Vidal" <[EMAIL PROTECTED]> said: > > jmmv84> Using plain text messages will make one think twice before > jmmv84> doing that, because he'll have to explain *why* he is > jmmv84> committing that at once. > > I totally agree with that. There are numerous messages saying that > the programmer fiddle with this and that function, created a new one, > removed an old one, but NOT ONE WORD about the overall change, its > intention or its reasons. Basically, that makes for crap > documentation.
On the other hand, that is the way we typically work. I often notice "little things" while I'm working on one "big thing". Would it be better to _not_ fix them? Or do one commit for each little thing? Documentation belongs in .texi files, not in commit messages. Commit messages should help you find when a change occured, and give pointers/hints about why, but the real reasons should be in more stable form. Otherwise, you can get oscillations; "changed to a linked list because it's faster on Windows", "changed to a red-black tree because it's faster on Gentoo" etc. If those comments were in a design file, it would be obvious what's happening. If they are just in the commit messages, it's much harder to notice. -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
