Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > To the contrary. As far as I can see, when calling `git merge`, Git > currently *does* read .gitattributes from the file, and if that fails, > falls back to reading that file from the index. Hmph. Assuming that the merge always goes in the index order, I think you are right. When we need to merge path/to/dir/.gitattributes, we would need to know all the .gitattributes files that may affect that path, so .gitattributes, path/.gitattributes, path/to/.gitattributes and the file being merged are all read into core before anything happens and these are kept in attr_stack while merging anything underneath path/to/dir/ hierarchy without being re-read from the filesystem. The original contents of path/to/dir/.gitattributes cached in the attr_stack will be discarded when we start to merge things outside path/to/dir (e.g. merging path/to/another/file), but at that point the contents of path/to/dir/.gitattributes no longer matters to the path being merged, so unless the merge somehow jumps around it is OK. It may be a fragile assumption in the longer term that the merge always goes in the index order, but I think the assumption holds in the current codebase, and the update planned immediately in the future.