resolve git conflicts for particular files by automatic merge all changes

Question

There is a project using github repositories. When there are conflicts to be resoled before merging pull request some 90% of conflict cases concern just one CHANGELOG file containing list of completed tickets, sth like:

## current

<<<<<<< HEAD
ISSUE-128 done some 128
ISSUE-131 done some 131
=======
ISSUE-125 done some 125
>>>>>>> ISSUE-125
ISSUE-126 done some 126
ISSUE-120 done some 126
ISSUE-123 done some 126

I wonder if there is a way to automate merge of this particular file (possibly by providing some configuration using i.e. gitignore format) with a simple rule to just accept the changes from both sides (as for the order its enough that the changes will be just next to each other, knowing how could be possible to control the order is secondary yet interesting). Additional rule could be to verify if there is always just one addition on each side and only then proceed with the automatic merge.

Ideally would be to have such configuration on github yet even local git solution would be helpful.

Answer 1

[Answer, slightly modified from comments.]

What you want here is usually called union merge, and this is actually built in to Git. It rarely does the right thing, but for this particular case, union merge is actually probably correct. You can set union merge for a particular file name using .gitattributes. See git merge, keep both for more about this.

Actually the only thing I'm still somehow worry about is that for a "more complex" conflicts I'd rather see that there is conflict to merge

Right: the main problem with union merge, I think, is that it always succeeds, even if the merge result is nonsensical. You need to remember that it is set up this way, and be careful to check the merge result every time.

(Personally I'd be happier with all of this if Git had it split out into a separate "resolve" command one could invoke on each file. I think the git merge-file command is, in fact, mostly what one wants here, except that it is a pain to use. With a more useable interface, instead of -X ours and -s ours and -X theirs and so on, and various merge drivers in .gitattributes, we could just let the merge conflicts happen, inspect them, decide which side(s) to keep if that suffices, and go with that. Of course if one goes much further down this road, one ends up with a GUI merge tool...)