"Philip Oakley" <philipoakley@xxxxxxx> writes: > The git book [1] and a few blog posts [2] show how to preserve files which > are in the current branch against changes that are on the branch being > merged in. > > e.g. (from [2]) > > echo '<filemane> merge=ours' >> .gitattributes && # commit > git config --global merge.ours.driver true > > (test) $ git checkout demo > (demo) $ git merge - > # <filename> contents are not merged and the original retained. > > > > However what is not covered (at least in the documentation ) is the case > where the file to be ignored is not present on the current branch, but is > present on the branch to be merged in. Hmph. Per-path 'ours' and 'theirs' kick in only after we decide to perform the content level three-way merge. I wonder what would (not "should", but "would with the current code") happen, with the same attribute setting, if the file being merged were not changed by ours but modified by the side branch? I suspect that we'd take the change made by the side branch. > Normal expectations would be that in such a case the new file from the > second parent branch would be added to the current branch. So I do not think this is not limited to "new file". Anything that a tree-level three-way merge would resolve cleanly without having to consult the content-level three-way merge will complete without consulting the merge.ours.driver; per-file content-level three-way merge driver (which is what merge=<drivername> mechanism lets you specify via the attributes mechanism) is not something you would want to use for this kind of thing. It is purely for resolving the actual content-level conflicts.