Search code examples
gitgitattributes

.gitattribute merge ours trow merge conflict

I have branch master and develop.

master branch contain:

  1. dist/app.js
  2. dist/app.polyfill.js

develop branch contain:

  1. dist/app.js

.gitattributes file contain:

dist/* merge=ours

$ git config merge.ours.driver true - used

When i try to merge master to develop dist/app.js is merged without conflicts but dist/app.polyfill.js trown merge error.

What i´m doing wrong?

Merge error

CONFLICT (modify/delete): dist/app.polyfill.js deleted in HEAD and modified in 682c04bb6342e545f70a5e936413904a0d57156b. Version 682c04bb6342e545f70a5e936413904a0d57156b of dist/app.polyfill.js left in tree. Auto-merging dist/app.js Automatic merge failed; fix conflicts and then commit the result.

Solution

  • First of all, this isn't a valid merge driver configuration. The merge driver configuration is supposed to take multiple arguments with percent patterns and produce a result in the file specified by %A. Yours doesn't do that; that it works at all (if it does) is pure luck.

    The other issue you're seeing here is that your driver affects only what Git does when it needs to perform a file-level merge, but not how certain other types of conflicts, such as modify/delete conflicts are handled. From the gitattributes(7) manual page (emphasis mine):

    The attribute merge affects how three versions of a file are merged when a file-level merge is necessary during git merge, and other commands such as git revert and git cherry-pick.

    In this case, you have a conflict because one side modified the file and the other side deleted it. Git determined that no file-level merge needed to occur because a modify/delete situation is always a conflict, so it didn't invoke your driver and just gave up. Note that a deleted file is qualitatively different from an empty file; the latter would merge, but the former does not.

    Based on the name of your directory, it sounds like you might be storing build artifacts in your repository. If so, that's generally discouraged because, as you've noticed, they don't merge well, and they tend to bloat the repository. You'd be better off using an artifact server, like Artifactory, or if this stored on GitHub, a release asset as part of a GitHub release.