On Thu, Feb 06, 2025 at 10:10:26PM -0800, Chris Torek wrote: > [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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx