Re: [PATCH v3 2/2] diff: teach diff to read algorithm from diff driver

> On Mon, Feb 20, 2023 at 09:32:52AM -0800, Elijah Newren wrote:
>
>>> I was thinking we would just use the tree-ish of the first one
>>
>> That would certainly simplify, but it'd be pretty important to
>> document.  (Incidentally, this kind of decision was my reason for
>> asking about all those special cases earlier, i.e. how to handle diff
>> between different commits, how to handle renames, how to handle bare
>> repositories, etc.)
>>
>> This kind of decision probably also means you'd need a variety of
>> testcases where .gitattributes is different in every commit & the
>> index & the working tree, and then you start testing several of the
>> possible pairings to make sure the right .gitattributes file is used
>> (e.g. (commit, commit), (commit, index), (index, commit), (worktree,
>> index), etc.)
>
> There may be some prior art here in how we handle mailmaps in a bare
> repository. In that case, we pull them from HEAD (or really any commit
> of your choosing, but the default is HEAD). That may seem a bit weird,
> but it matches how non-bare repositories work, which read the mailmap
> from the working tree.
>
> So likewise, even looking at an old commit like "git show HEAD~1000", in
> a non-bare repository we will read .gitattributes from the working tree,
> which means it is (roughly) coming from HEAD. In some ways that is good
> (there may be improvements to the attributes) and in some ways it is
> weird and confusing (the meaning of the attributes may have been
> different back then, or the two histories may even be somewhat
> unrelated!). So I think you can make an argument either way on what is
> useful, but harmonizing the non-bare and bare cases seems like the best
> place to start.