Re: Merge conflicts in .gitattributes can cause trouble

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2016, 17:30 UTC
Message-ID: <xmqqmvi1pntm.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1610181437180.197091@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.