Custom git merge union strategy for a Changelog

Question

We have an ONGOING.md file where each developer adds item when pushing code.
It looks like :

### Added
- item 1

### Changed
- item 2

It happened all the time that lines got overwritten when pulling/pushing code so I added a .gitattributes file at the repo root :

ONGOING.md -text merge=union

I expected that every written line got kept after that, but that's not the case, overwrites still happen.

What is the proper way to deal with this?

Edit:

OK, it just happened so I copy/paste content of my terminal :

$ more fab/hotfix/ONGOING.md 
### Added

$ nano fab/hotfix/ONGOING.md; git commit fab/hotfix/ONGOING.md -m "update ongoing"

$ more fab/hotfix/ONGOING.md 
### Added
- add slug column to BO fack topic  admin  page

$ git pull
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 14 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (14/14), done.
From gitlab.com:kraymer/website
   a740fe8a0..12d531e8d  hotfix              -> origin/hotfix
First, rewinding head to replay your work on top of it...
Applying: add slug column to BO fack topic  admin  page
Using index info to reconstruct a base tree...
M   fab/hotfix/ONGOING.md
Falling back to patching base and 3-way merge...

$ more fab/hotfix/ONGOING.md 
### Added
- shared task for old notifications to be deleted

I thought the sentence "Falling back to patching base and 3-way merge..." meant git resolved a conflict, so the merge driver should come into play, no?

Edit2:

So quoting @VonC :

But if the 3-way merge completes without conflicts... no merge driver called.

So I guess my problem can be rephrased like : how can I configure git so a 3-way merge on ONGOING.md ends up with a conflict when 2 developers edit the same section (like ### Added in my previous example), such that the merge driver comes into play ?

If we reconsider my example in Edit1, I don't get how git ends up picking up the other dev line rather than mine or both.

Answer 1

Merge drivers are called in case on merge conflicts.

If overwrite are still happening, check if the developers are not doing at some point a push --force, overriding the remote history with their own.
Or if they somehow ignore the changes pulled (by saving their local copy from their IDE, overriding what was just pulled)

Make sure they have:

git config --global pull.rebase=true
git config --global rebase.autostash=true

That will force them to do a local resolution of ONGOING.md, replaying their own commit on top of the ones pulled from the remote.

---

I thought the sentence "Falling back to patching base and 3-way merge..." meant git resolved a conflict, so the merge driver should come into play, no?

No: it just means it needs the common ancestor to make the merge.
If that common ancestor shows common lines being modified/merged, then yes, a conflict would occur, and the merge driver would be called.
But if the 3-way merge completes without conflicts... no merge driver called.

Answer 2

I noticed that my question got some traction over the time so it could be of interest to people how I dealt with the problem.
The concern was to have a way to keep a log of ongoing changes across different branches.
To avoid conflicts when editing, we did not host the text files directly in the repository but in the project wiki repository : so we have one wiki page per branch, and we do edits via the gitlab web interface that handle conflicts in case of parallel edits nicely.

Gitlab wiki are git repositories too, so this setup keeps the advantages of having versioned ongoing changelogs while avoiding pitfalls of resolving manually text conflicts (conflicts occur only when two users edit the wiki at the same time whereas they appeared more or less after each edit with the previous setup).