Re: renormalize histroy with smudge/clean-filter

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Feb 9, 2025, 02:33 UTC
Message-ID: <CALnO6CCUYSM69V4CRiFV=EvQLCC7LCdzuY2gqryj_G_nAWqj-w@mail.gmail.com>
In-Reply-To: <20250208232651.GJ30202@raven.inka.de>

On Sat, Feb 8, 2025 at 6:28 PM Josef Wolf <jw@raven.inka.de> wrote:

Show 26 quoted lines

>
> Hi Elijah,
>
> On Sat, Feb 08, 2025 at 01:43:05PM -0800, Elijah Newren wrote:
>
> > Ooh, nice catch.  If folks had an appropriate .gitattributes file in
> > place in older versions of history, they probably wouldn't have gotten
> > into the mess.
>
> Well, you can't assume that paople get it right from the very start. An
> important use case of git is fixing errors made in the past, right?
>
> In my case, I had no choice. I HAD to commit those propritary data files
> as-is, because I had no clue how they are structured and how those hashes are
> calculated. As time passed, I learned what I need to do to smudge+clean those
> files. But at that time a whole bunch of commits were already done.
>
> On this roadtrip, I had to modify those .gitattributes files in various ways.
>
> The only variant of those .gitattributes file which will work properly is the
> newest one. And this is also the variant wich will work for all the olter
> commits.
>
> 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.

For the starting point of an operation that eventually invokes other operations, where the start clearly uses one gitattributes, it _might_ be reasonable to assume that would propagate down to the other operations.

But when subsequent operations logically operate on older history, it also seems reasonable (and unsurprising) to "do what the repository intended at that specific commit." Git assumes the latter and provides a way for you to indicate the former. Perhaps it's worth an explainer somewhere?

-- 
D. Ben Knoble