Generating GNU-style Changelog from git commits

Generating GNU-style Changelog from git commits

[David Chanters]

[Please Cc me on replies.  Thanks!]

Hi,

Some projects maintain a ChangeLog file, which looks something like this:

2011-01-01  David Chanters  <d.c@example.com>
        * foo/bar.c (some_function):
         Changed static variable in some_function to auto.

etc., etc.

Here "foo" is some directory relative to the top-level directory the
.git one is in.

These ChangeLog files are maintained manually, irrespective of the/any
revision control system in use.  I am wondering if it's possible if
the project is in Git to be able to automatically append to such a
ChangeLog file with each commit automatically, and have it formatted
in the style above.

Is this possible?  Is it a solved problem?  If not, and I wanted to
try myself, could someone point me at the git-specific tools I'd need
to know to use to achieve it?

TIA!
DC

Re: Generating GNU-style Changelog from git commits

[Chris Packham]

On 17/04/11 10:46, David Chanters wrote:
> [Please Cc me on replies.  Thanks!]
>
> Hi,
>
> Some projects maintain a ChangeLog file, which looks something like this:
>
> 2011-01-01  David Chanters<d.c@example.com>
>          * foo/bar.c (some_function):
>           Changed static variable in some_function to auto.
>
> etc., etc.
>
> Here "foo" is some directory relative to the top-level directory the
> .git one is in.
>
> These ChangeLog files are maintained manually, irrespective of the/any
> revision control system in use.  I am wondering if it's possible if
> the project is in Git to be able to automatically append to such a
> ChangeLog file with each commit automatically, and have it formatted
> in the style above.
>
> Is this possible?  Is it a solved problem?  If not, and I wanted to
> try myself, could someone point me at the git-specific tools I'd need
> to know to use to achieve it?
>
> TIA!
> DC
> --

Shouldn't be to hard, there are numerous hooks that could be used either 
on the developer end (post-commit), on the server end (post-update) or 
even when a maintainer applies a patch (post-applypatch). See 
githooks(5) for more info on what hooks are available and what args are 
passed.

There is also the possibility of generating this changelog at the time 
of release. I'd advocate this approach as it would allow you to edit the 
changelog to make it more useful to readers.

Either way the actual format could probably be generated with 'git log 
--format' (someone else may reply with better plumbing commands, but my 
initial response is use git log).

My 2 minutes worth of reading git-log(1) got me this

   git log --format="%ai%x09%an <%ae> %n%x09* %s" REVISIONS

Which for a chunk of gits pu branch gave me this (my mail client munges 
some of the longer lines)

2011-02-17 13:54:28 -0800	Junio C Hamano <gitster@pobox.com>
	* Merge branch 'js/cherry-pick-usability' into pu
2011-02-17 12:29:33 -0800	Junio C Hamano <gitster@pobox.com>
	* Merge branch 'so/submodule-no-update-first-time' into pu
2011-02-17 12:29:32 -0800	Junio C Hamano <gitster@pobox.com>
	* Merge branch 'jc/grep--no-index-pathspec-fix' into pu
2011-02-17 09:18:46 -0700	Spencer E. Olson <olsonse@umich.edu>
	* t7406: "git submodule update {--merge|--rebase]" with new submodules
2011-02-17 09:18:45 -0700	Spencer E. Olson <olsonse@umich.edu>
	* submodule: no [--merge|--rebase] when newly cloned
2011-02-16 14:39:00 -0800	Junio C Hamano <gitster@pobox.com>
	* grep --no-index: honor pathspecs correctly
2011-02-16 05:08:23 -0500	Jay Soffian <jaysoffian@gmail.com>
	* Teach commit about CHERRY_PICK_HEAD
2011-02-16 12:20:35 -0500	Jay Soffian <jaysoffian@gmail.com>
	* Introduce CHERRY_PICK_HEAD

Which is pretty close. You could experiment with more format specifiers 
to get the info you need.

Hope that helps
- Chris

Re: Generating GNU-style Changelog from git commits

[Marcus D. Hanwell]

On Sat, Apr 16, 2011 at 8:53 PM, Chris Packham <judge.packham@gmail.com> wrote:
> On 17/04/11 10:46, David Chanters wrote:
>>
>> [Please Cc me on replies.  Thanks!]
>>
>> Hi,
>>
>> Some projects maintain a ChangeLog file, which looks something like this:
>>
>> 2011-01-01  David Chanters<d.c@example.com>
>>         * foo/bar.c (some_function):
>>          Changed static variable in some_function to auto.
>>
>> etc., etc.
>>
>> Here "foo" is some directory relative to the top-level directory the
>> .git one is in.
>>
>> These ChangeLog files are maintained manually, irrespective of the/any
>> revision control system in use.  I am wondering if it's possible if
>> the project is in Git to be able to automatically append to such a
>> ChangeLog file with each commit automatically, and have it formatted
>> in the style above.
>>
>> Is this possible?  Is it a solved problem?  If not, and I wanted to
>> try myself, could someone point me at the git-specific tools I'd need
>> to know to use to achieve it?
>
> Shouldn't be to hard, there are numerous hooks that could be used either on
> the developer end (post-commit), on the server end (post-update) or even
> when a maintainer applies a patch (post-applypatch). See githooks(5) for
> more info on what hooks are available and what args are passed.
>
> There is also the possibility of generating this changelog at the time of
> release. I'd advocate this approach as it would allow you to edit the
> changelog to make it more useful to readers.

Something I wrote a few years ago does this for us. It may not be
perfect, but there was a desire to have a Changelog in our released
tarballs,

https://github.com/cryos/avogadro/blob/master/scripts/gitlog2changelog.py

If there are better ways of doing this I would certainly be
interested, but have not spent much time on this since writing the
initial script. We had a similar desire, but didn't want to end up
resolving conflicts around a file in version control.

Marcus

Re: Generating GNU-style Changelog from git commits

[David Chanters]

On 17 April 2011 02:47, Marcus D. Hanwell <marcus.hanwell@kitware.com> wrote:
> https://github.com/cryos/avogadro/blob/master/scripts/gitlog2changelog.py
>
> If there are better ways of doing this I would certainly be
> interested, but have not spent much time on this since writing the
> initial script. We had a similar desire, but didn't want to end up
> resolving conflicts around a file in version control.

Thanks, all.  I shall look into it.   :)

David