How we solved GitLab's changelog conflict crisis

about.gitlab.com

17 points·mikece··13 comments

Git supports merge drivers to do things like this: https://git-scm.com/docs/gitattributes#_defining_a_custom_me...

Debian has had a merge driver for its changelogs for a while: https://salsa.debian.org/dpkg-team/dpkg/commit/9b98847665d8b...

This!

I get that the article's solution technically does remove a merge collision problem, but this adds other non-automatable™ problems that require giving humans special instructions because of the exceptions to the rule.

Use standard solutions for standard problems people. And dont do a normal merge if you dont want a normal merge. Dont fight the symptoms, look at the cause.

This solution is neat, but Git also has a very simple built in solution: https://git-scm.com/docs/gitattributes#gitattributes-union

union is bad in general, there is a risk of bad merge

works pretty well until you really need to have similar lines from each branch

Funny thing, i had this idea back in 2015, i even implemented a tool for that,

old blog post: https://medium.com/@nettsundere/on-reducing-changelog-merge-...

that was the tool https://github.com/nettsundere/cyberlog

I imagine just sorting the changelog entries per release (maybe split into sections) would get you quite far, too.

A number of Python projects use a fairly similar way of managing changelogs: https://github.com/hawkowl/towncrier

So does Python itself:

https://github.com/python/core-workflow/tree/master/blurb

This is akin to database migrations being used to generate the schema in the end. A very Rails-like solution.

Still waiting for them to resolve the "we moved from azure to Google" problem.

"We heard you don't like tech giants hosting your code so we found another tech giant. "

TL;DR - ChangeBlog -> MD ;)

Reply on news.ycombinator.com