When creating a ChangeLog entry for *.m4 files, we should mention the Autoconf
macro name. git's default heuristic is to look at the previous line that
starts with a non-whitespace character. Unfortunately, in our *.m4 files, we
have C code and changequotes command frequently indented at column 0;
Hi Marc,
> (Do I have to
> do something about the ChangeLog entry or will it be auto-generated
> from my Git commit message?)
The ChangeLog entries are not auto-generated, no. We want the ChangeLog
entries to be essentially in sync with the git commits. This means, you
typicall
Joel E. Denny wrote:
On Tue, 17 Jan 2012, Jim Meyering wrote:
Below is a patch that adds a --no-cluster option, which I believe does
what Stefano wants. I want it too. OK to push?
Hi Joel,
Thanks. That looks fine, but please adjust the preceding comment
to keep in sync with the new
Joel E. Denny wrote:
On Mon, 26 Dec 2011, Jim Meyering wrote:
I think the result is an improvement, but it is still not as readable as I
would like, or maybe it's just not as readable as I am used to (git log
output). Why? ... Because when some clumped entries are adjacent to a
Hi Jim,
On Mon, 26 Dec 2011, Jim Meyering wrote:
I think the result is an improvement, but it is still not as readable as I
would like, or maybe it's just not as readable as I am used to (git log
output). Why? ... Because when some clumped entries are adjacent to a
multi-paragraph one, the
On Tue, 17 Jan 2012, Jim Meyering wrote:
Below is a patch that adds a --no-cluster option, which I believe does
what Stefano wants. I want it too. OK to push?
Hi Joel,
Thanks. That looks fine, but please adjust the preceding comment
to keep in sync with the new behavior.
Thanks. I
Stefano Lattarini wrote:
On 12/23/2011 05:19 PM, Jim Meyering wrote:
However, I would prefer an adaptive/hybrid solution: if a commit log
is composed of two or more paragraphs, keep it in a separate block.
Otherwise, merge entries that would otherwise have a date--name--email
header
Hello Gnulibers.
Currently, the `gitlog-to-changelog' script clusters ChangeLog entries with
the same date together, placing them under a single date line in the
generated output.
So we have something like this:
$ ./build-aux/gitlog-to-changelog -- -n 2 76d222b
2011-12-22 Jim Meyering
Stefano Lattarini wrote:
Hello Gnulibers.
Currently, the `gitlog-to-changelog' script clusters ChangeLog entries with
the same date together, placing them under a single date line in the
generated output.
So we have something like this:
$ ./build-aux/gitlog-to-changelog -- -n 2 76d222b
On 12/23/2011 03:38 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
Hello Gnulibers.
Currently, the `gitlog-to-changelog' script clusters ChangeLog entries with
the same date together, placing them under a single date line in the
generated output.
So we have something like
Stefano Lattarini wrote:
On 12/23/2011 03:38 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
Hello Gnulibers.
Currently, the `gitlog-to-changelog' script clusters ChangeLog entries with
the same date together, placing them under a single date line in the
generated output.
So we have
On 12/23/2011 04:11 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
I hope the above argument will make you reconsider this position;
...
Position? I had not taken a position. Any feature request should be
accompanied by justification. The questions above were simply my attempt
to
Stefano Lattarini wrote:
On 12/23/2011 04:11 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
I hope the above argument will make you reconsider this position;
...
Position? I had not taken a position. Any feature request should be
accompanied by justification. The questions above
On 12/23/2011 05:19 PM, Jim Meyering wrote:
However, I would prefer an adaptive/hybrid solution: if a commit log
is composed of two or more paragraphs, keep it in a separate block.
Otherwise, merge entries that would otherwise have a date--name--email
header identical to the preceding one.
I'm fixing a posteriori a few syntactically incorrect (or at least unusual)
ChangeLog entries:
--- ChangeLog.orig Sat May 21 18:53:06 2011
+++ ChangeLog Sat May 21 18:52:50 2011
@@ -56,7 +56,7 @@
* tests/test-perror2.c (main): Enhance test.
test-perror: check for strerror
At Sunday 18 July 2010, Bruno Haible wrote:
Hello Stafano,
Thanks for the suggestion. Eric Blake already suggested the same
thing. It is planned that in a month or so, the
git-merge-changelog is merged to a project of its own, then
receives a test suite, and then we'll start to add more
Hello Stafano,
Some projects (like Automake) have the policy of keeping multiple
ChangeLog entries having the same author and date lumped togheter,
preferring e.g.:
2000-01-01 Foo Bar nob...@example.com
Add foo
Add bar
over:
2000-01-01 Foo Bar nob
Hello gnulibers.
Some projects (like Automake) have the policy of keeping multiple
ChangeLog entries having the same author and date lumped togheter,
preferring e.g.:
2000-01-01 Foo Bar nob...@example.com
Add foo
Add bar
over:
2000-01-01 Foo Bar nob...@example.com
FYI, this change removed 1500 lines of ChangeLog content:
Author: Bruno Haible [EMAIL PROTECTED]
Date: Sun Feb 18 15:10:28 2007 +
New module 'math'. math.h replaces mathl.h.
I presume that was accidental and have restored those lines.
Using git, you can see the diff like this:
Paul Eggert [EMAIL PROTECTED] writes:
I noticed that recent changes (merging from gettext, for example)
added many ChangeLog entries whose dates disagree with when the change
was installed into gnulib. Hence gnulib's ChangeLog file appears not
to be in reverse chronological order
. ChangeLog entries until 2006-01-25 below.
And the original ChangeLog entries are added, with their original
date, in the normal tab column.
Well, I find Paul's style better used it already in other projects.
The GCC project uses a similar style as well. The indentation makes it
very clear
[EMAIL PROTECTED] writes:
Emacs doesn't highlight this new format well. Care to bring this idea
up on, e.g., emacs-devel?
I'm a bit stretched for time right now, but you're welcome to bring it
up, as an Emacs issue or as a GNU coding standards issue or both.
I suppose it'd be nice if Emacs
22 matches
Mail list logo
