8

I'm working on a git project that uses lots of branches. For the most part, this has been a really great workflow. I'm happy merging between branches, love being able to cherry-pick code, and the overall lifecycle that comes with git and other dvcs's.

I've got one pain point that is really hurting. How to maintain a changelog.txt.

I've found it hurts whenever I do a merge (the changelog.txt often conflicts), and when cherry-picking commits I've accidentally managed to pickup changes that really weren't desired.

I'd love to see a good answer to this problem.

Rob Dawson
  • 1,349
  • 10
  • 21
  • You could probably come up with some clever solution using [git notes](http://www.kernel.org/pub/software/scm/git/docs/git-notes.html) but my guess is that eckes' solution (or something like it -- you may not need a changelog entry for every single commit) is much simpler. – Tyler Mar 01 '11 at 08:01
  • When do you update your changelog? After every commit? Can you wait until it gets merged back into a releasable branch? We use a script to generate release notes after tagging which uses the oneline commit format. Maybe you can come up with something similar? – Brian Riehman Mar 01 '11 at 13:12
  • [Why maintain traditional detailed changelog in modern world with svn/mercurial/git?](http://stackoverflow.com/questions/3712969/why-maintain-traditional-detailed-changelog-in-modern-world-with-svn-mercurial) – gavenkoa Feb 22 '15 at 18:22

1 Answers1

6

You could annotate your checkin comments and parse these comments once you're ready to ship a new version of your software (I guess that's the most common use case for providing a changelog).

The comments could be built the following way (obviously only those belonging to commits that do modify something noteworthy):

WHAT WHERE DESCRIPTION

Where WHAT could be

  • FIX for bug fixes
  • CHG for changes
  • NEW for new code

WHERE should be one word describing the module where WHAT was done. Following these two informations, you provide your DESCRIPTION describing the modification in deep.

Once you're ready to ship, get the logs since the last version and parse them. The logs can be obtained using git log tagname_of_last_version... See the man page of git log for output and filtering options.

eckes
  • 64,417
  • 29
  • 168
  • 201
  • thanks for the suggestion. I've played with this type of strategy before. I'd probably do an extra prefix to try and highlight that the message should be included in the changelog. – Rob Dawson Mar 02 '11 at 00:53
  • @Rob Dawson: for us, the prefixes listed under `WHAT` indicate that this message should go to the changelog. If we just remove some typos, we won't prefix the log message with `WHAT`... – eckes Mar 02 '11 at 06:47
  • nice one. Good plan all round. – Rob Dawson Mar 03 '11 at 04:57