Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi, > > On Fri, 2 Mar 2007, Simon Josefsson wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > I saw that in your mail already, and I find the style cvs2cl outputs >> > ugly. >> >> Well, if you don't follow the GNU ChangeLog format, then please call it >> something else. The format is well documented. > > Well, it is still ugly. I mean, really ugly. Like in "it's easier to > script, therefore I don't fix it" ugly. > > And yes, the format is well documented. For example, it includes the > function names in brackets, which both my patch and cvs2cl do not do. > These function names actually got me interested, and I would have tried to > generate them automatically, too. Including the function names in brackets is optional, but the wrap style is inherent in the format. However, it sounds like a nice idea to automatically add function names when there aren't too many of them. Possibly one should be able to use a regexp to restrict the set of function names (useful, e.g., for only having brackets for public API functions). I recall that "diff" has an option to print C function names in patches, maybe that could be used. >> > No charset problem. In Git commit messages, the first line is special. >> > It is the so called "oneline" description. If you wrap the oneline, >> > it's your fault, not Git's. >> >> But I want more than the oneline comment in the ChangeLog? There is no >> size limit on ChangeLog messages, and having as much information as >> possible available is better. > > With Git, it is encouraged that you write useful commit messages. There > are commits where the patch consists of just a line change, and the > message of a really long text. For a good example, look at commit > v1.4.0-rc1~50: the commit message has 49 lines of text, but the patch only > changes 5 lines. > > If you are serious about "having as much information", include the > _complete_ commit message. Yes, I do want the complete commit message. While 49 lines of ChangeLog entry is a lot, it is not completely unheard of. Although the recommendation in the GNU ChangeLog specification to move such lengthy discussions to manuals or source code comments is often good. >> Anyway, for now I'll be settling with the (just announced) git2cl since >> it gives me the most flexibility. > > In hindsight I agree with Junio that a script is better for this purpose. Yup, I think it will be more flexible to keep it outside of git. It makes it easier to do some un-git-ish things (like handling those "empty" CVS log messages). /Simon - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html