Re: renormalize histroy with smudge/clean-filter

From: Josef Wolf <jw@raven.inka.de>
Date: Feb 7, 2025, 10:45 UTC
Message-ID: <20250207104510.GE30202@raven.inka.de>
In-Reply-To: <CAPx1Gvc2piLT=p+dvzcJPTMDQAAjQfz__O4KiRWs-fOMg8dpTw@mail.gmail.com>

On Thu, Feb 06, 2025 at 10:10:26PM -0800, Chris Torek wrote:

Show 19 quoted lines

> [First]
> 
> > On Thu, Feb 06, 2025 at 02:40:06PM +0100, Josef Wolf wrote:
> >
> > >    foreach $commit original-branch-commits
> > >        git cherry-pick $commit
> 
> [then]
> 
> >On Thu, Feb 6, 2025 at 12:07 PM Josef Wolf <jw@raven.inka.de> wrote:
> > I've done a lot of try and error with this approach and have come to the
> > conclusion, that cherry-pick totally mis-behaves in the presence of
> > clean/smudge filters.
> 
> I suspect, actually, that the biggest problem here is that cherry-pick
> defaults to working by using merge. Given that you want to create
> a new linear set of "cleaned" commits, you don't want to use
> `git cherry-pick` at all. Just restore the files from the original
> commit, then add and commit.

Ummm... That's far beyond my git expertise...

I completely fail to understand why git insists to operate on smudged files in many situations.

IIUC, once clean/smudge are installed, all internal operations should be done on clean files. So why do I need this "git add --renormalize ." at all and (in the case of cherry-pick) there is not even any way to renormalize before picking.

But maybe my understanding is too simplicistic here...

-- 
Josef Wolf
jw@raven.inka.de