Corinna Vinschen writes: >> Uh, what? You need to keep a blank line between the (brief) commit >> message and any ChangeLog lines, > > That's a rule? In theory the subject line is totally useless for a > ChangeLog entry, but if that's required, ok, fine.
Not so much a rule, but rather a consequence of the possible interaction of patches sent via email. The subject line might have been folded if it gets too long, so the first paragraph becomes the first line of the commit message. The formatting of the rest of the message (after the first blank line) is kept and becomes the actual commit description. >> the first line and any following >> (wrapped) lines will be the single-line commit message. > > Yuck! Who had the terrible idea to fold all commit lines into a single > line? Why bother to write detailed log message at all if it gets this > messy and unreadable? Just leave a blank line after the first. The first line is the subject of the commit, if you will. It gets shown for "git log --oneline" and other such things, so it's good to keep it short. > The question is, can this be automated so that a commit automatically > adds the entry to the ChangeLog file and commit the ChangeLog file at > the same time? Or is there some problem with that approach? That way lies madness, but you could do this in a pre-commit-hook on the server. If you want to keep a ChangeLog file, I'd rather just edit this file (C-x 4 a in Emacs) and then copy the text into the commit message. The other option is to generate the ChangeLog only when a release is made and then tag that commit, typically via some special target for make. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs