git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Josefsson <simon@josefsson.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, junkio@cox.net
Subject: Re: [PATCH] Add --pretty=changelog
Date: Sat, 03 Mar 2007 15:12:42 +0100	[thread overview]
Message-ID: <877ityquud.fsf@latte.josefsson.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0703021419520.22628@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Fri\, 2 Mar 2007 15\:09\:49 +0100 \(CET\)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Fri, 2 Mar 2007, Simon Josefsson wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

      reply	other threads:[~2007-03-03 14:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.63.0702271621120.22628@wbgn013.biozentrum.uni-wuerz burg.de>
2007-02-27 15:21 ` [PATCH] Add --pretty=changelog Johannes Schindelin
2007-02-27 15:38   ` Nicolas Pitre
2007-02-27 15:57     ` Johannes Schindelin
2007-02-27 23:11       ` Eric Wong
2007-02-27 23:22         ` Junio C Hamano
2007-02-28  1:58   ` [PATCH 4/3] Rename --pretty=changelog to --pretty=gnucl, and fix a bug Johannes Schindelin
2007-02-28  2:52     ` Nicolas Pitre
2007-02-28 12:44       ` [PATCH] --amend Rename --pretty=changelog to --pretty=gnucl Johannes Schindelin
2007-03-02  8:49         ` Junio C Hamano
2007-03-02 14:28           ` [PATCH] print_wrapped_text: fix output for negative indent Johannes Schindelin
2007-03-02 14:29           ` [PATCH] --pretty=gnucl: avoid line wrapping before the comma Johannes Schindelin
2007-03-03 12:38           ` [PATCH] --amend Rename --pretty=changelog to --pretty=gnucl Junio C Hamano
2007-03-03 14:13             ` Johannes Schindelin
2007-03-03 20:07               ` Junio C Hamano
2007-03-01 15:23   ` [PATCH] Add --pretty=changelog Simon Josefsson
2007-03-01 18:15     ` Johannes Schindelin
2007-03-01 18:27       ` Shawn O. Pearce
2007-03-01 18:40         ` Johannes Schindelin
2007-03-02  4:39       ` Junio C Hamano
2007-03-02  9:14       ` Simon Josefsson
2007-03-02 10:03         ` Junio C Hamano
2007-03-02 10:15           ` Simon Josefsson
2007-03-02 14:09         ` Johannes Schindelin
2007-03-03 14:12           ` Simon Josefsson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ityquud.fsf@latte.josefsson.org \
    --to=simon@josefsson.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).