On Sat, Feb 08, 2025 at 09:33:05PM -0500, D. Ben Knoble wrote: > > So no, I don't see why using any of the older variants of this .gitattributes > > would make any sense. > > The original question said > > > Why on earth would one want a changing filter setting during a rebase? > > Can anybody outline a use-case for changing filter during operaion? [sic] > > But I'll answer this one—general operations on older history can't use > a newer gitattributes declaration without explicit instruction because > they'd have to know from which future to pull. Remember Git can > branch, so (even assuming we had a fast way to calculate this, which > AIUI we don't) from a single commit there can be multiple valid future > commits with different gitattributes. Yes, this is the way .gitattributes work. And to be honest, I always found it strange that this setting travels along the history. But there is also ~/.giconfig, which has the drawback that in won't travel with the repo. IMHO, it would make more sense to have some sort of global storage which travels along with the repo. -- Josef Wolf jw@xxxxxxxxxxxxx
