Constant merge conflicts with CHANGES.md

[joshgoebel]

@egor-rogov @allejo Do you know how other projects [with a changelog] solve this? This is starting to drive me nuts. Because ever contribution changes this file and is basing their work on master (like they should) this means ever single time I merge any PR I have to do thru this ridiculous merge conflict dance with the changelog.

It's not hard per-se, it's just annoying, and then all the CI runs again (for no reason), etc..

[egor-rogov]

It's clear to me that CHANGES should be generated out of commit messages. Marcos had mentioned some tool for it in #1780.

[joshgoebel]

I had that thought... that requires a lot of discipline to get the same level of detail we have now though... sometimes I'll split a commit into 2-3 lines if it makes sense to explain it that way. True, SOMETIMES I'd accomplish that with 3 commits (which would just work), but that rarely works for 3rd party contributors where the commit history is typically squashed.

And even I find myself annoyed sometimes because I'll click the "update with master" button in the UI and then that destroys my perfect commit history because it does a merge rather than a rebase.

I'll go read marcos thoughts...

OMG that tool does look pretty awesome. I might check it out when we get closed to releasing 10.0 and see how it would work.

[allejo]

I'm personally very fond of the way the Jekyll team handles their changelog. They exclude the changelog commit from the PR and it is only done after the PR is merged; this solves the conflict problem. Additionally, for the changelog entries, they use the PR titles and not individual commits so a PR can have multiple commits. Since a PR should be one feature only (ideally), having that be the changelog entry makes sense.

See jekyll/jekyll#7427 as an example.

[joshgoebel]

Additionally, for the changelog entries, they use the PR titles and not individual commits so a PR can have multiple commits.

We do this generally (PR titles) but I've seen lots of valid exceptions. Sometimes when working on a language you can fix or add 5 features but all related to that language - and all worthy of mention. Meanwhile 5 separate PRs would just be brutally annoying if that were a requirement.

and it is only done after the PR is merged

Ah, looks like they have a bot to do it... that's certainly one valid solution.