From: John Cai Date: Fri, 24 Feb 2023 17:44:47 GMT Subject: Re: [PATCH v3 2/2] diff: teach diff to read algorithm from diff driver Message-ID: <95D30379-4B31-4197-8D2F-71369E72514D@gmail.com> In-Reply-To: Hey Peff, On 22 Feb 2023, at 14:47, Jeff King wrote: > 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. Thanks for the historical context and suggestion here > > 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). Makes sense to me thanks John > > -Peff