Reputation: 34281
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.
Upvotes: 5
Views: 2179
Reputation: 5059
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.
Upvotes: 5