Re: renormalize histroy with smudge/clean-filter

From: Josef Wolf <jw@raven.inka.de>
Date: Feb 9, 2025, 08:53 UTC
Message-ID: <20250209085332.GK30202@raven.inka.de>
In-Reply-To: <CALnO6CCUYSM69V4CRiFV=EvQLCC7LCdzuY2gqryj_G_nAWqj-w@mail.gmail.com>

On Sat, Feb 08, 2025 at 09:33:05PM -0500, D. Ben Knoble wrote:

Show 14 quoted lines

> > 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@raven.inka.de