Re: renormalize histroy with smudge/clean-filter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux