5

Let's say I'm merging a pull request and want also to accompany the merge with a line in the changelog:

> git merge --no-ff otherguy/feature-x
> echo "Feature: X" >> changelog
> git commit -am "Changelog update"
> git push

A similar thing is possible in a single commit:

> git merge --no-ff --no-commit otherguy/feature-x
> echo "Feature: X" >> changelog
> git commit -am "Merge otherguy/feature-x + changelog"
> git push

So that the same commit will contain both the merge and the file changes.

Granting that I always update the changelog when merging from the downstream repositories, here is a question:

Is the latter way a sane thing to do and what unexpected consequences might show up later?

Update: As for why I need a separate file changelog when I already have a git log, the one in the file is more pruned (entry or so per merge, not per commit), sometimes better worded and in a certain format (e.g. debian/changelog). So, it's for external usage.

bereal
  • 32,519
  • 6
  • 58
  • 104

1 Answers1

5

You should first consider if it really is useful to keep a changelog committed in the repository, when you have git there to keep the changelog in the first place.

Also, adding things in merge that didn't exist in either branch is called an evil merge, and is not a good practise anyway.

Community
  • 1
  • 1
Kalle Pokki
  • 4,939
  • 2
  • 17
  • 18
  • 1
    As for git log vs a file changelog, my concern are things like debian/changelog, i.e. in a certain format, so there would be something like `dch -e` instead of `echo`. – bereal Jan 16 '13 at 08:44
  • 3
    In that case you should change the file as a separate commit, and not try to hide the change in the merge. – Kalle Pokki Jan 16 '13 at 08:49