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. And then that machinery would probably be enough to let people ask for specific things on top (like "git show --attributes-from=HEAD~1000 HEAD~1000" if they really wanted). -Peff
