Set git attributes to union changes in the CHANGELOG to reduce merge conflicts

[cwperks]

Description

This is a quality of life PR to drastically reduce the number of merge conflicts and prevent maintainers from having to constantly resolve conflicts only in the CHANGELOG file.

By setting the gitattribute merge=union, this tells git to automatically take the union of both sides of the conflicts without maintainers having to manually determine how to perform the merge.

Related Issues

Resolves #18475

Related to https://about.gitlab.com/blog/gitlab-reduced-merge-conflicts-by-90-percent-with-changelog-placeholders/

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

❌ Gradle check result for 9ec0df0: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[prudhvigodithi]

Thanks @cwperks this really helps, just curious to see the behavior do you have sample PR from fork repo?

[cwperks]

@prudhvigodithi I do not, but I could merge this into security repo first and demonstrate it working.

Essentially, by specifying CHANGELOG.md merge=union its telling git that if there are merge conflicts then take the union from both sides. Since the sides on the left and the right are mutually exclusively and should both be included, union makes sense for this file.

[rishabhmaurya]

@cwperks Indeed, this will make life so much better. Is it a possibility to avoid gradle checks when changes are made to this file? as this coupling makes it even worse.

[cwperks]

@cwperks Indeed, this will make life so much better. Is it a possibility to avoid gradle checks when changes are made to this file? as this coupling makes it even worse.

@rishabhmaurya It is possible, but I haven't scoped out what would be required for that. On the k-NN repo they use paths: on the GHA trigger like this: https://github.com/opensearch-project/k-NN/blob/main/.github/workflows/test_security.yml#L9-L17

If the PR contains changes on any of those paths then it triggers the GHA. I'm wondering if that can be inverted to exclude running GHAs if changes are only in documentation files like .md files.

[github-actions]

✅ Gradle check result for 9ec0df0: SUCCESS

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.60%. Comparing base (6ad6f4e) to head (9ec0df0).
Report is 6 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #18474      +/-   ##
============================================
- Coverage     72.66%   72.60%   -0.06%     
- Complexity    67858    67868      +10     
============================================
  Files          5521     5521              
  Lines        312541   312541              
  Branches      45364    45364              
============================================
- Hits         227113   226935     -178     
- Misses        66903    67089     +186     
+ Partials      18525    18517       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rishabhmaurya]

I'm wondering if that can be inverted to exclude running GHAs if changes are only in documentation files like .md files.

+1

[rishabhmaurya]

I'm only concerned about users, who might change the ordering of entries, where merge union may end up with duplicate entries.

[jmazanec15]

This is pretty cool - I think there is some logic for excluding via paths-ignore (https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)

[cwperks]

I'm only concerned about users, who might change the ordering of entries, where merge union may end up with duplicate entries.

I'm not sure how it would look from a reviewers perspective, but something like that should be flagged during review.

This is pretty cool - I think there is some logic for excluding via paths-ignore (https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)

Nice, that would work well for the core repo where the list of files/file extensions to exclude is smaller then the list to include.

[peternied]

@cwperks Thanks for this suggestion, it sounds good in theory, lets see how it works in practice by merging this change :D

[andrross]

@rishabhmaurya We have logic that skips the gradle check depending on which files are changed, and that does include CHANGELOG.md because of the *.md rule:

OpenSearch/.github/workflows/gradle-check.yml

Lines 19 to 32 in dd61c5d

	check-files:
	runs-on: ubuntu-latest
	outputs:
	RUN_GRADLE_CHECK: ${{ steps.changed-files-specific.outputs.any_changed }}
	steps:
	- uses: actions/checkout@v4
	- name: Get changed files
	id: changed-files-specific
	uses: tj-actions/changed-files@v46.0.5
	with:
	files_ignore: |
	release-notes/*.md
	.github/**
	*.md