Re: [PATCH] Add --pretty=changelog

Johannes Schindelin [off-list ref] writes:

Hi,

On Fri, 2 Mar 2007, Simon Josefsson wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

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.

quoted

quoted

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.

quoted

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